When to use the '--no-ff' merge option in Git
fast-forward, git, git-merge
Solution
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.
Problem
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?