Git Tip: Reviewing and Committing a branch full of changes

Git Tip: Reviewing and Committing a branch full of changes

Pascal Rapicault, DJ Houghton and I have been hacking on a new feature for p2. Since p2 has been migrated to Git, we created a new branch and started hacking away. We were not very concerned about each individual commit since this work was mostly experimental. We took some wrong turns, performed a few quick and dirty hacks, and generally left our branch in rough shape. However, during the process we learned a lot and finally got feature working, but we certainly didn’t want to merge this hack into master.

If 15 years of software engineering has taught me anything, it’s that you should not be afraid to hack, learn, throw away and then implement properly. Git makes this so much easier.  Here’s what we did.

To review, clean-up and commit this feature, we started by switching to our new branch and we squashed all the commits into a single commit. We did this because we didn’t care about the individual commits that made up this feature. (Note: Don’t do this on a production (shared) branch since this will re-write your history).

To squash commits, use interactive rebase.

Once we had a single commit that represented the feature, we rebased on top of master and merged the feature to the master branch. Now, we could stop here but this included all the hacks, false starts and ugly code that we don’t want in our final repository. We used a little trick that Chris Aniszczyk mentioned to me.  We reset the git index, but left the files in their updated state (read more about the Git index on Alex Blewitt Git Tip of the Week). This is done using a soft reset.  Make sure you don’t reset your index if you have already pushed your changes to a remote repository.

This essentially returns you to a state where all the files have out-going changes that represent the work we did. Now we could use git diff (or better yet, the s synchronized view in Eclipse) to review the commit, clean up the code, remove the unwanted changes, test our feature and finally, commit the feature properly (using a proper commit comment to indicate exactly what we did).


  • Deepak Azad
    Posted at 8:11 am, October 19, 2011

    Once you have a single commit, why can’t you simply keep ‘ammending’ that commit in the non-master branch to remove all the hacks. Once you have a ‘good single commit’ you can them simply merge/rebase changes with master and push. (EGit history view allows you to compare HEADs of 2 branches, just like you would view outgoing changes in CVS).

    Or did I miss something here ?

  • Deepak Azad
    Posted at 9:05 am, October 19, 2011

    Ok, it is a matter of habit then. I try to avoid doing a ‘reset’ as I might accidentally reset too much 🙂

  • Posted at 3:32 pm, October 19, 2011

    Another solution would be to create a diff/patch between the start and end of the experimental branch and apply that to master.

    Advantages: Doesn’t need any advanced commands, doesn’t tamper with history, more clearly communicates intent.

    Drawback: Doesn’t tamper with history so anyone can see how you messed up (but that’s mostly a pride thing).

  • Bogdan
    Posted at 11:10 am, October 21, 2011


    You can use the “ammend” feature only when you are working alone on the branch. But even then you lose the option of reverting/removing only parts of your changes, and not all …

    So I am all for using commit commit commit, and before rebasing in master, if the history is irelevant, squash everything.