A few days ago I ran into a situation when I forgot to add
--no-ff when merging a feature branch into master. The result was a mess.
State before the final merge:
State after switching to master and doing
git merge feature (bad state!):
State after donig
git merge --no-ff feature instead (good state):
The flow of events was as follows:
- Create ‘feature’ branch off master
- Add some commits to feature and to master
- Merge latest master into feature to resolve any conflicts
- Work on the feature a little more
Now the feature is ready to be merged back into master. Since “feature” has all commits that “master” has plus some more, git by default will simply fast-forward “master” to be the same as “feature”, and the feature branch will effectively befcome the new master. It does not look good: feature and master commits are now mixed in the main branch line. The annoying part is that if it has already been pushed to origin, it is not easy to fix without force-pushes, and force-pushes are not always enabled. The end result is that you get very confusing commit history for the rest of the life of the project.
If you do use
--no-ff, the history is preserved much better: all feature commits are kept in a side branch and only the merge is in the main line.
Click to download the batch file that demonstrates the problem (rename from .txt. It creates the “bad” case by default. Pass it
--no-ff argument to create history without fast forward.