Fast-forward merge requests
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.
Overview
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.
Enabling fast-forward merges
- On the top bar, select Menu > Projects and find your project.
- On the left sidebar, select Settings > General.
- Expand Merge requests.
- In the Merge method section, select Fast-forward merge.
- 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.