Some people like to see lots of branches and the way they are merged together in their git history. Others like to have nice straight line.

Some companies have a development workflow in which the only way to add to the "master" branch is to send a pull-request, get it reviewed, approved and then merged into "master". For them it might be useful to enforce that merging into master can be done only with a fast-forward merge.

There are several ways to enforce it or at least to gently nudge you in the chosen direction.

Aaron Bonner wanted to Only Allow Git Fast-forward Merges to Avoid Ugly Merge Commits and he suggested execute

git config --global merge.ff only

That will add an entry to your ~/.gitconfig file:

    ff = only

and it will require that you only merge branches that can fast-forward. That basically forces you to either rebase before merging, or turn off this configuration, or to force your way through using

git merge --no-ff

Alternatively you can execute the following command while inside a git workspace

git config --local merge.ff only

This will add the same entry to the .git/config of the current project. This way the enforcing only happens in specific projects.

Of course all this is on the client side and not on the server.

Enforce fast-forward to a single branch only

Adding the following to the .git/config file of your project will enforce the "merge only with fast-forward" rule on the "master" branch only.

[branch "master"]
    mergeOptions = --ff-only

This is also describe by Marko Vuksanovic in Git tips: Use only fast-forward merges (with rebase)

Team Foundation Server

TFS allows the admins to set branch policies. Among the several features one can Enforce a merge strategy, but as far as I can see only No fast-forward merge and Squash merge are available.

Atlassian BitBucket

The documentation seems to indicated that the admin of a project can set the available merge strategies, but all I managed to do was to set the default merge strategy. It indeed stopped me from accepting a pull-request that could not be merged using fast-forward. However I was still able to pick a different merge strategy when I was about to accept the pull-request.

Maybe I have not looked close enough.


As far as I know GitHub does not support requiring fast-forward when you accept and merge a pull-request.


As I can see one can set fast forward merge as the only acceptable merge strategy.