I cannot praise the revision-control tool git highly enough, and often use it as a buffer between SVN and me. Much of my professional work flow involves fixing a bug here, fixing a bug there — lots and lots of small changes in many different branches. git is the perfect tool for this kind of work. And it is fast.
One of my favourite features is interacting rebasing. This allows you to re-arrange, and even delete, commits in the log. I mostly use this to squash commits together, so the log that the rest of the team sees is much easier to read. One can rebase in a couple of ways:
git rebase -i HEAD~3
git rebase -i <commit>
In the latter case <commit> is the commit you wish to keep. All commits after that one are then presented for rebasing. I like this because it is pretty quick to issue
and note the commit you wish to keep, and then pass this to the command. To use the first form, one more count down commits, and that can be a little tedious at times — the example above shows how to rebase the first 3 commits. Of course, both commands are just different ways of specifying commits.
I am someone who likes to commit regularly, often when I have a small, though significant, change in place. It might even break my build, but having git between me and the corporate SVN repo allows me to do this.
I can continue to work, making commits as I go and then finally finishing the change. Instead of then pushing all those commits to the corporate repo I squash them into one working commit, so I don’t spam the company with multiple checkin messages. This is highly recommended if your work flow is similar.
Amending the latest commit message
Another favourite command of mine is:
git commit --amend
Nothing bugs me more (well, perhaps magic numbers) than a commit message I wrote, that contains a typo. The amend command allows you to quickly fix errors in your latest commit message.