Improving GitHub code review

Making GitHub code review better for large pull requests.

GitHub’s code review tools are pretty good

We do all of our code review in GitHub’s pull requests. These have a bunch of nice features: they have nice syntax highlighting; they store comments against the PR, but also show those made on individual commits; any comments against lines which have changed subsequently are hidden by default; the comments support nice formatting; and more.

In some cases, they come up short

Imagine this pull request:

  1. Author adds commits A, B, and C.
  2. Reviewer adds some line comments, and some comments to the pull request as a whole.
  3. Author adds commits D and E to address those comments.
  4. Author asks Reviewer to look at the latest changes.
  5. Reviewer has a problem. How do they comment on just those commits?
  6. Repeat steps 2-6.

This can happen with or without a workflow based around rebasing, although heavy use of --autosquash will tend to lead to more commits starting with fixup! or squash!, as it vastly reduces the overhead of rewriting history later.

Currently available workarounds

In this case, there are several options, none of which are ideal:

How to fix it

I would like GitHub to allow reviewers of a PR to select which changes they want to see, and use some intelligent defaults to give them relevant changes automatically.

That’s it.

I wrote Gitique, which is an extension for Chrome and Firefox, to demonstrate this. It does the stupidest possible thing that could work: given that every added line in the overall PR view must have the same content in the most recent change set, it styles lines to be context lines if they haven’t changed since the last review comment, and hides files which haven’t changed at all.

Here’s a quick demo:

Reviewable is a hosted tool which does this in a much more advanced way, with a very slick demo. It is much more fully-featured than Gitique: it handles rebases properly, allows for commit sets to be selected which don’t include the latest commit, and can expand and collapse sections individually.

For teams who want to adopt this wholesale, this looks like an excellent option. Gitique is basically a feature request, but Reviewable is an actual working product. (Gitcolony seems similar to Reviewable, but I haven’t tried it.) And if GitHub implemented this natively, I would be very happy.