Git Pull Requests for the lazy developer

Jeroen van Dijk
Jeroen van Dijk

18 augustus 2013

I’ve been working with Git as my primary version control system for a while now. Occasionally I still have to work in some Subversion repositories as well, but when returning to a Git based project it is always a big relieve.

While working with Subversion and having a good branching model gives you a lot of control, the demand for more power in the projects I work on made Git a reliable partner. With Git you have so many powerful options at hand to switch from context continuously. Easy branching, pulling, stashing and merging are all actions I do within an hour of my work day.
During the day I work with a team of 5 persons or more, on new features, features that are in a staging area and of course the application that is in production. And everyone is sending in Pull Requests for the different features.

As a standard procedure in our development process a PR sent via Github is always checked by another developer and our CI server Jenkins. Both need to give an ok, before the PR request is merged. As a developer of course you can check the PR on syntax and the chosen approach for the solution, but you can’t see the code in action.
To be able to check that, you need to:

  • setup a remote,
  • create a branch from the correct feature,
  • pull the remote branch into your branch,
  • merge conflicts that might exist after the pull.

The fact that this many steps are needed bugged me. With so much power at hand this should be more easy… and it can be more easy! From now on, I only do git pr {nr} and start checking the PR immediately.

Setup Git PR

Setting up an alias for the git pr command is as simple as one line of code in the projects’ or your global .gitconfig file. In our case a PR is always sent to the upstream remote. You can change this into any remote name you’d like to use of course.

[alias]
    pr = "!pr() { git fetch upstream refs/pull/$1/head:refs/remotes/upstream/pr/$1; git checkout upstream/pr/$1; }; pr"

I really like this solution because I have:

  • no additional remotes,
  • no merge issues,
  • no additional local branches

If you want to have more of these aliases, I can recommend Mathias Bynens’ dotfiles which are on Github. My fork has the above describe logic.

This blogpost is a copy of the original version which can be found at jrdk.nl.