git-code-review: using Git and GitHub for daily code reviews
I like to do code reviews. I can’t say that I always like the activity itself; it depends of course on who writes the code and on the quality of the code. But I like to make sure that the code I’m going to work with later is reviewed. This might be my perfectionism or some obsession with control, but what’s important is that reviewed code will in general be better than not reviewed code, and no one will argue with that.
Reviews let you catch obvious bugs before they even reach QA (“extra comma here, this will break IE”), or potential bugs that would only reappear 4 months later when no one remembers what this code does. They help you make sure that everyone follows similar practices and coding guidelines, and let you transfer knowledge easily (“you know, there’s a new method X in Rails 4 that you could use instead”).
In smaller projects I usually use Gitifier, a git commit notifier for OSX that I wrote some time ago. It lets me review the work of others almost in real time, just minutes after it’s pushed to the repository.
But in my current project (~10 developers) this is physically impossible – new commits and branches are created so often that the constant distractions drive you mad pretty quickly. So I started using GitHub’s web interface instead, and I made a habit of reviewing latest commits every day before I start coding. But the process of finding which commits exactly were new wasn’t perfect. I was never sure which commit was the last one I’ve seen, and having multiple branches didn’t help either, since GitHub shows them all on one list, mixed together.
At this point I decided to write a simple tool to automate this. The result is a Bash script which I called git-code-review.
Here’s how it works: it creates a review subdirectory inside .git in your project’s working copy; in that directory it creates one file for each branch in the repository, and each file stores the hash of the last commit from that branch that you’ve reviewed. (If you know how git branches work in practice, you might notice this is exactly how git stores branch references in .git/refs – that’s true, except these change every time you do git fetch or git pull, and the review data only changes when you do a review.)
The script is extremely simple to use: there are no options, you just need to run git code-review in your project directory. The first time you do it, it will just remember the current state of the branches. Then you can run it again every morning (or once a week, or whenever you want) – and it will tell you how the branches have changed since then. You don’t need to remember or track the commits anymore, it will do that for you. It will also show you GitHub compare links, so you can just click on them:
Fetching latest updates...
remote: Counting objects: 365, done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 270 (delta 213), reused 176 (delta 119)
Receiving objects: 100% (270/270), 92.89 KiB | 97 KiB/s, done.
Resolving deltas: 100% (213/213), completed with 74 local objects.
From github.com:jsuder/holepicker
abc0825..0a711db master -> origin/master
Branch origin/master updated: 313a63b..0a711db
-> https://github.com/jsuder/holepicker/compare/313a63b...0a711db
So far it’s been very helpful in my daily reviews, so I hope it will be of use to someone else too. As usual, feedback / pull requests / issue reports etc. are very welcome.