Workflow for GitHub-based code review

Question

I'm considering using GitHub as our primary tool for doing code review. With features like in-line commenting and compare view, it seems to have a lot of features that tools like Gerrit have on offer.

Has anyone else used GitHub for this? If so, what is your workflow? And what have your experiences been doing so, both positive and negative?

As I get some thoughts on this and sort out what will work best for us, I'll edit my question to share my own proposed workflow.

EDITED with proposed workflow

Step 0. Set up a post-receive hook using the awesome reviewth.is.

Then:

1. Commit as usual with commit -a -s, but in the commit message append #reviewthis @username.

2. If the build fails, the review is skipped until the build is restored.

3. Reviewer comments on commit line-by-line or at the file level.

4. GitHub automagically notifies reviewee of comments.

5. Reviewer notifies reviewee by email when comments are completed with a review summary.

6. Reviewee replies to reviewer comments within GitHub, allowing the project access to history of code reviews.

My biggest problems are with Step 2 and Steps 4/5. Gerrit works nicely for not asking for reviews unless the build succeeds; I'd like a way to do this within GitHub. Steps 4/5 also have the potential to get annoying (multiple emails) and reduce the automatic nature of the review process (requiring an emailed summary).

We use Hudson as our build server, if that helps.

Any thoughts on these problems would also be helpful.

Answer 1

I've used it for this. The workflow I've used is to do your work on a topic branch and send a pull request on that branch. The review person(s) examine the code and the commits, using by-line comments (and by-commit). The coder takes that feedback and does a destructive rebase on that topic branch, re-pushes it (rewriting the history on his github repo), then the review cycle repeats until it's acceptable to merge.