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.
Permalink
Wow…
1 Create ‘feature’ branch off master?
2 Add some commits to feature and to master?
Is there a reason not to follow normal Gitflow? That will keep you from such troubles.
Branch feature from DEVELOP, never modify DEVELOP or master directly, merge DEVELOP (or RELEASE/N.NN) to MASTER after PROD deployment
Permalink
> Is there a reason not to follow normal Gitflow?
Yes, but it’s a matter of another post. These troubles will apply to any flow that has feature branches, including gitflow. Just replace ‘master’ with ‘develop’, and keep in mind that ‘commits’ could be pull request merges, it does not matter. You will fall into the trap if
1. You create a feature branch off the main one (whatever the name).
2. Both the main and the feature branches advance.
3. You merge main into feature to get the feature code up-to-date with the latest changes in main.
4. You merge feature back into main and forget
--no-ff.Of course, if any and all merges are done through some kind of pull request system that automatically adds
--no-ff, you’re good. Otherwise, this may happen to you, gitflow or not.Permalink
With lots of merges I never ever got into this situation over few years, so I guess whatever tools I’ve been using were quietly adding –no-ff for me (Visual Studio, SourceTree, Bitbucket…)
Permalink
OK, them the title should be “don’t use command line” 🙂
Permalink
True. I use command line only for emergencies. Usually while helping somebody to “recover” commits that were “lost” in their local repository by mistake.