In a team environment, where multiple developers work on the same codebase, branching and merging are part of everyday life. The way branches are merged can make or break team collaboration and CI stability. Merge strategies aren’t just technical details — they actively shape how teams collaborate.
Among the different strategies supported by Git, the fast forward merge is particularly worth a close look. This article will break down what it is, why teams use it, the trade-offs it introduces, and best practices for deciding when to adopt it.
What is Fast Forward Merge?
A fast forward merge is a type of merge where the destination branch pointer advances to the head of the source branch without creating a merge commit. As a result, the commit history stays perfectly linear, with no extra merge commit or complex commit graph.
Advantages of Fast Forward Merge
✅ CI remains Green
When combined with `Pipeline must succeed` merge check, moving the destination branch HEAD to the source branch ensures the CI remains green after the merge.
✅ Linear history
No merge commits clutter the log, keeping history clear and easy to read. Though the community is split on this regard
Limitations and Points of Attention
⚠️ Requires rebases before merging
For fast forward to work, your feature branch must be fully up-to-date with the destination branch. That means regularly rebasing.
This is especially true for teams creating pull requests daily
Example
If 5 people want to merge their PRs, only one will be able to merge directly. The other 4 will need to:
– Rebase
– Wait for their pipeline to succeed
– Hope no one else merged in the meantime
– Finally merge
This repetitive cycle can be time-consuming, resource-intensive and frustrating, especially if you have to rebase multiple times before your changes make it into the target branch.
Best Practices
The best strategy depends on two key factors:
– The number of pull requests created daily
– Whether the develop/master branch CI must **always** stay green
👨💻👩💻: For team publishing only a few pull requests a day, sticking with traditional merge commits is recommended.
A rare CI failure can occur if the target branch has evolved before merging. (example: one commit adding a test file has been added to the target branch and one commit that modify this tested file on the source branch will likely make the CI fail)
As an order of magnitude, in our team of 9 developers, working across several repositories, we’ve only seen a single CI failure after a merge in the past two years
One option to further mitigate the risk on Gitlab is to activate the merge result pipelines which runs the pipeline on the combined source + target branches merged together. It is only available on Premium / Ultimate account. If you can, we strongly advice you to activate those!
👨💻👩💻👨💻👩💻👨💻: For teams with higher volumes of pull requests or a strict CI requirement, it’s better to adopt more advanced mechanisms like merge trains. Merge trains queue incoming merge requests and automatically rebase and combine them with the destination branch in sequence, ensuring that the resulting merged state passes all tests before being integrated.
⚖️: Note that other factors may also tip the balance one way or the other: story size, code architecture, branch lifespan and even your release strategy.
Conclusion
Fast forward merging does offer a consistently successful CI on the main branch at all times… But it also comes with the cost of rebasing regularly.
Ultimately, the best approach depends on your team’s size, collaboration practices, and how critical it is to keep your target branch green at all times. By carefully weighing these trade-offs and applying the right tooling, you can choose a merging strategy that supports both your delivery speed and code quality goals.
