Phil for Humanity Phil for Humanity
A Guide for the Survival of Humankind and Helping the World, Society, and Yourself.



Git Merge Fast Forward versus No Fast Forward


By default, the "git merge .." command uses the fast forward feature. However after years of working with Git, I believe this fast forward feature has three major flaws that should convince everyone to stop using this default option.

The first reason that Git merge with fast forward will require users to rebase their changes, if their changes are not already off of remote's head. In my opinion, rebasing a branch is bad, because it will delete any data from the original branch. For instance, if your inspection tool tracks versions of files using SHA numbers, then rebasing will obliterate those SHAs and create new SHAs without any useful linkage. As a result, inspection tracking data will be permanently lost (by the way, it is requirement for SEI CMM to keep this data).


The second issue with Git merge with fast forward is rebase timing. In large software teams (i.e. more than 10 people), I have seen software developers rebase their branch, optionally re-inspect their changes, re-build to verify that the code still works, possibly test too, then try to merge with fast forward with a failure, because another software developer merged their changes before the first developer finished merging. Then the first developer repeats the rebase, inspection, build, test, and merge to only fail again and again for the same reason. If a team is extremely large (i.e. more than 50 people), then most merges occur during off hours or without inspections, builds, or any quality assurances.

Even without rebasing, the final issue with Git merge with fast forward will be lost of merge data. For instance, assume a developer's branch has more than one SHA and is then merged to the parent branch using Git merge with fast forward. Now assume that this merge broke the entire software application, and this change was decided to be removed. To revert this merge, then the only way to hopefully determine which SHAs to revert is by either looking at all the SHAs' commit messages or code changes to determine the range of SHAs that broke the build. Obviously, this is a very manual, time consuming, and error prone process even for anyone involved in the original merge.

I know that some people have worked around this issue by always squash rebasing their branches before merging with fast forward to alleviate this issue, however this brings us back to the first two issues with rebasing.

Of course, Git merge with no fast forward has issues too. First, it will create an empty merge commit SHA that will add to your version tree. This SHA is great for determining what needs to be reverted, if needed. However, it does clutter the version tree, thus making it more difficult to read to the untrained person. Furthermore, these extra SHAs could add considerably size to the Git repository, and ultimately slow down development because of the shear quantity of data.

In my opinion, using Git merge with no fast forward might not be perfect, but it is much better than the alternative of Git merge with fast forward.

by Phil for Humanity
on 20150728

Related Articles
 » Git Merge
 » Git Rebase Walk Through
 » Two-Way Radios are better than Cell Phones