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.
Screen Shot 2011 10 17 at 10.29.24 PM Git Tip: Reviewing and Committing a branch full of changes

Screen Shot 2011 10 17 at 10.33.54 PM Git Tip: Reviewing and Committing a branch full of changesOnce 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.

Screen Shot 2011 10 17 at 10.43.12 PM Git Tip: Reviewing and Committing a branch full of changesThis 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).

 

5 Responses to “Git Tip: Reviewing and Committing a branch full of changes”

  1. Deepak Azad says:

    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 ?

  2. Ian Bull says:

    I could have done that and it would have produced the same thing. I guess I’m just used to reviewing changes as ‘outgoing’ changes in the Synchronize view. By doing the reset –soft, all my changes where now ‘outgoing’, so it was really easy to go through and figure out what I really wanted in. In your case, all the changes would have been diffs between the branches. (Diff between the branches vs. diffs between workspace and index, I guess it’s basically the same thing).

  3. Deepak Azad says:

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

  4. 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).

  5. Bogdan says:

    Hey.

    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.

5 responses so far

Written by . Published in Categories: Planet Eclipse

Author:
Published:
Oct 18th, 2011
Follow:

Twitter LinkedIn Google+ GitHub