My Pull-Request Workflow!

posted by qmx on 11 September 2014

One of the common tasks of the opensource project maintainer role is dealing with pull requests.

You won’t see me clicking that awful green button at GitHub’s web ui. NEVER. I think reviewing contributions is something that needs to be taken seriously and the best way of giving it the due importance is to actually running the code locally, not just spilling 👍 after a poor glance at the changes.

Let’s be honest here, it’s tempting! :)

Here’s my magic one-liner, which I friendly call pullify (well, not exactly mine, stolen from several parts of the internet, and fitted to my needs, hence mine :P )

git config --global alias.pullify "config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'"
  • cd into a fresh cloned github-hosted project
  • run git pullify
  • run git fetch

now watch the magic happening

remote: Counting objects: 29, done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 29 (delta 6), reused 15 (delta 2)
Unpacking objects: 100% (29/29), done.
 * [new ref]         refs/pull/1/head -> origin/pr/1
 * [new ref]         refs/pull/11/head -> origin/pr/11
 * [new ref]         refs/pull/2/head -> origin/pr/2
 * [new ref]         refs/pull/5/head -> origin/pr/5
 * [new ref]         refs/pull/7/head -> origin/pr/7
 * [new ref]         refs/pull/8/head -> origin/pr/8

from now on, you can easily check a pull request by running git checkout -t origin/pr/<pull request no>

now you can go, rebase the branch if needed, and merge it back to master - i tend to ensure we end up with a linear tree, but keeping the branch separated (using git merge --no-ff). In this case if anything goes wrong I can revert a bunch of related commits at once :)

hope you find this useful :)

emergency handle picture taken from here