The good news is that GitHub actually supports a much better alternative which works really nicely. As a maintainer and reviewer of many GitHub repositories, I’ve been continually surprised how many people are unaware of this simple trick; perhaps it’s due to the hole in GitHub’s pull request documentation which I mentioned above? The trick is simply this:

Rewrite the history of your local branch corresponding to the pull request, so that the issues revealed during the review of the pull request are addressed. Do a force push (i.e. a git push command which includes the -f option).

I won’t go into details here about how to rewrite history. git history rewriting via git rebase (with fixup , squash ), git commit --amend etc. is something of an art form, and there are already many great resources out there which there would be no value in me replicating.

So really this whole blog post is a long way of saying:

When you force-push a new head for a pull request branch, GitHub handles it gracefully and automatically updates the pull request in the way you want.

It’s almost like magic. For example, if a reviewer commented on two hunks in the original pull request, and your force-push effectively rewrites one of those hunks but not the other, then the GitHub pull request UI will get updated to say something like “@reviewer commented on an outdated diff” for the rewritten hunk, but any outstanding review comments on the changed hunk will be presented as before the force-push.

Now don’t get me wrong – GitHub is not perfect. In some (but not all) ways, it is inferior to Gerrit’s review system which is better at exposing the complete history of the review cycle. I previously wrote another blog post examining GitHub’s review system in more depth. But in general, it’s usually plenty good enough.