Adam December 12th, 2010
Filed under: Computers and Technology , Work/Professional
Tags: development, Git, source-control
Let’s say you are working on a large feature or update that requires a bunch of commits to complete. You finish up with your work and are then ready to merge it onto your master branch.
For example, here is the history of my drupal repository after some work updating the cas module to the latest version (and to support the new version of phpCAS):
As you can see, I have a number of commits, followed by a merge in with the new module code, followed by some more commits.
Now, if I merge my feature branch (
master-cas3-simple) into the
git merge master-cas3-simple
then the history will look like this:
While the history is all there, it isn’t obvious that all of the commits beyond “Convert MS Word quote…” are a single unit of work. They all kind of blend together because git performed a “fast-forward” commit. Usually fast-forward commits are helpful since they keep the history from being cluttered with hundreds of unnecessary merge commits, but in this case we are loosing the context of these commits being a unit of work.
To preserve the grouping of these commits together I can instead force the merge operation to create a merge commit (and even append a message) by using the
--no-ff option to
git merge --no-ff -m "Upgraded CAS support to to cas-6.x-3.x-dev and phpCAS 1.2.0 RC2.5" master-cas3-simple
This results in the history below:
As you can see, merging with the
--no-ff option creates a merge commit which very obviously delineates work on this feature. If we decided that we wanted to roll back this feature it would be much easier to sort out where the starting point before the feature was.