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