<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=325868) </details> <!--IssueSummary end--> ### Problem to solve I'd like my team to use a fast-forward merge-request strategy that uses an 'option to merge' to resolve a non-fastforward situation as opposed to 'option to git rebase'. Some of my rationale for this is mentioned in [this article](https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1) I suspect that folks might say that I should use "every merge creates a merge commit". This is not acceptable, as most times fast-forward merges are appropriate and should not create extra merge commits when not necessary. In a nutshell: do fast-forward merges when available, but resolve divergent histories using git merge instead of git rebase. ### Intended users Gitlab project owners. (Setting up Gitlab merge-request to do merge instead of rebase) ### User experience goal Gitlab project owner can setup the merge request to offer a git-merge instead of git-rebase when necessary on a merge-request. ### Proposal Add a new merge request strategy similar to fast-forward-merge that instead of saying _When conflicts arise the user is given the option to rebase_, says _When conflicts arise the user is given the option to **merge**_ ### Links / references https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 \~feature