by Ryan Irelan
I’ve been using the Git Flow branching model for a while (but at times not very strict). Maybe because it’s buried in the original article but I didn’t realize until now that there’s a very good reason to not allow fast-forwards 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.
If you do
git merge without the
--no-ff option then
it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the –no-ff flag was used.
I’ve been there. Using
--no-ff would’ve saved me a lot of time.
If you aren’t already familiar with it, Vincent’s A successful Git branching model is a canonical article on using Git.