Fast-forward merge requests (FREE)

Sometimes, a workflow policy might mandate a clean commit history without merge commits. In such cases, the fast-forward merge is the perfect candidate.

With fast-forward merge requests, you can retain a linear Git history and a way to accept merge requests without creating merge commits.

When the fast-forward merge (--ff-only) setting is enabled, no merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch can be fast-forwarded.

When a fast-forward merge is not possible, the user is given the option to rebase.

NOTE: Projects using the fast-forward merge strategy can't filter merge requests by deployment date, because no merge commit is created.

Enabling fast-forward merges

1. On the top bar, select Menu > Projects and find your project.
2. On the left sidebar, select Settings > General.
3. Expand Merge requests.
4. In the Merge method section, select Fast-forward merge.
5. Select Save changes.

Now, when you visit the merge request page, you can accept it only if a fast-forward merge is possible.

If a fast-forward merge is not possible but a conflict free rebase is possible, a rebase button is offered.

You can also rebase without running a CI/CD pipeline. Introduced in GitLab 14.7.

The rebase action is also available as a quick action command: /rebase.

If the target branch is ahead of the source branch and a conflict free rebase is not possible, you need to rebase the source branch locally before you can do a fast-forward merge.

Fast-forward merges prevent squashing commits

If your project has enabled fast-forward merges, to merge cleanly, the code in a merge request cannot use squashing during merge. Squashing is available only when accepting a merge request. Rebasing may be required before squashing, even though squashing can itself be considered equivalent to rebasing.