When to use the '--no-ff' merge option in Git

Question

A Successful Git Branching Model recommends to use --no-ff when merging branches:

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. […]

Yes, it will create a few more (empty) commit objects, but the gain is much bigger that that cost. Unfortunately, I have not found a way to make --no-ff the default behavior of git merge yet, but it really should be.

Understanding the Git Workflow, however, recommends not to use --no-ff:

So you add a new rule: “When you merge in your feature branch, use –-no-ff to force a new commit.” This gets the job done, and you move on. […]

The --no-ff band-aid, broken bisect, and blame mysteries are all symptoms that you’re using a screwdriver as a hammer. […]

Both approaches seem reasonable for difference scenarios, but what is considered "good practice?"

When do you use --no-ff, when do you not, why?

Answer 1

It's really dependent on what you're trying to do. My rule of thumb is that if the merge "means something" I use the --no-ff option. When the merge doesn't really mean anything and you might have used a rebase there's no reason to use --no-ff.

The thing with git is that it's a very powerful tool, and you can use it in many ways - most of which are not wrong. Asking what's the "right way" to do it is like asking what's the right way to paint a picture.

At least for me it's an evolving set of ways I like to do it, with frequent discussions in the team of how we want to collaborate on the code - from this we try to derive a kind of "how it's done here" standard, but it's just our way of doing it.