Version control seems to be one of my favorite subjects for blogging; here’s a slightly new thing – a tutorial style thing showing off the coolest bits of GIT I’ve come across. This is part 1, offering tips for easy GIT usage especially for people coming from a dissimilar VCS.
Tip 1: Commit Often. Really Often.
Git offers a great number of features, but only for commits. Unlike other VCSs though, a commit isn’t final; you can still play with the ordering, combine commits, drop them, move them however you see fit. There is no down-side to committing often, if you end up with a big commit mess, use interactive rebasing to organise it all again.
Interactive Rebase
Suppose you’re developing your stuff on a branch called my_branch which is based on the master branch shared with others. You’ve taken tip 1 and you’ve ended up with a big mess of commits with no logical ordering or cohesion. Interactive rebasing allows you to reorder, combine and drop commits.
git rebase -i master my_branch
Will bring up $EDITOR with a list of all commits between master and my_branch. If you change the order of commits in this list, it will change the order of the commits in your branch. Replace the “pick” keyword with “s” to squish a commit in to the previous one. Delete a commit from that list and it will be deleted from your branch. Save and exit and GIT takes care of the rest.
In this way you can organise, say, a new feature in to a series of logically separated actions for easy review by your peers.
Tip 2: Pro: Rebase changes history. Con: Rebase changes history.
OK so rebasing is great. You can move your changes on top of a newer base or, like above, you can reorganize your commits to be more useful. Be very very careful though as you must never rebase something that someone else has access to.
Rebasing changes history but it doesn’t leave a marker anywhere saying what it has done. If someone has pulled your branch and you rebase it, their version won’t be updated to reflect this. They will have to remove their copy of your branch and pull it again from scratch.
Tip 3: Branches are cheap; use them for everything
Unlike some other VCSs, branching is very easy to do and merging back is just as easy. Separating your working tree in to different branches for each feature for example can allow you to test each feature on a stable base. You can leave the “master” branch for tracking upstream and working in private branches that others aren’t going to be annoyed if you break.
In particular, if you’re starting out with GIT and aren’t sure how to do something, branch off and try it there. If it works, merge it back, if it fails kill the branch and start again.
Like a lot of things though, use this tip with care. If you end up with a massive branch, getting it merged back in to the mainline gets harder and harder. Both because there’s more likely to be conflict and also because the final version is going to be hard to review. In short: Big branches eventually have the same problems as any patch bombs; be careful.