<!--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=1511) </details> <!--IssueSummary end--> See https://gitlab.com/gitlab-org/gitlab-ee/issues/895#note_20922445. When the fast-forward merge method is selected, the rebase button will be shown if the source branch is not up-to-date with the target branch. However, when we squash, we could just as easily apply the squashed commit on top of the target branch without a rebase, as long as there are no merge conflicts. From the backend side, this isn't too difficult, but the UX is quite confusing. When the source branch isn't up-to-date with the target branch, you can: 1. Rebase the merge request. (Followed by a merge.) 2. Rebase and merge in one step. 3. Squash and merge, even if the MR is not rebase-able.