Tutorials

Pull request proficiency: Fetching abilities unlocked!

Nicola Paolucci

Nowadays applying a fix to a project is as easy as creating a fork - which conjures up a full remote copy of the project for you to hack on - selecting the file you want to change, pressing Edit and committing your fixes.

What if you are at the receiving end of a pull request (abbreviated PR in the following) instead? Using a polished web UI is great and often that's all you need. Click a button to Approve, click a button to Merge and you're done.

But that's not always the case! It's a common occurrence to have to download the changes included in a pull request(PR) locally, run a few tests, see how they look in your IDE to make sense of what was done.

The steps to download - more explicitly fetch and checkout - your colleague's or contributor's pull requests are conceptually simple but they become even easier if you know a couple of important details and tips.

So let me guide you to a better understanding of the command line facilities git gives you to handle pull requests from the command line with ease.

Before we start: enrich your shell prompt with branch name and status

I am always surprised by how many people have a bare command prompt that doesn't show the git branch they are on or whether they have modified/uncommitted files in their working directory. If you thought - Hey that's me! - allow me to help you and blow your mind at the same time!

Please do yourself a favor and install something like the awesome liquid prompt which will give you excellent annotations on the status of your git working directory (and will support any other VCS, too):

(In the above screenshot you see my prompt alerting me that I am on branch newbranch and have added 5 lines to the files I track in my working directory and I have removed 0)

Everyone working in the same repository

If you work on the same repository with your team the process of checking out a pull request is very straight forward: just fetch and checkout the branch from which the pull request was created:

Get all the branches that were published on your shared repository:

git fetch origin

Create a local branch that tracks the remote branch you're interested in:

git checkout -b PRJ-1234 origin/PRJ-1234

Now you can diff, merge, test your heart out of this:

git diff master
./run-tests.sh

When you're happy just go back to the Web UI and provide feedback or Approve the change outright.

Contributors working in their own forks

The process changes a bit when some of the contributors work in separate forks. In this case you can fetch the remote branch where the contribution or feature was committed:

Add the contributor's remote first:

git remote add jsmith http://bitbucket.org/jsmith/coolproject.git

Collect all the latest updates from origin first, your main repository:

git checkout master
git fetch origin
git merge master

Get all the branches that were published on the contributor's fork:

git fetch jsmith

Create a local branch that tracks the remote branch you're interested in:

git checkout -b jsmith-PRJ-1234 jsmith/PRJ-1234

Now you can diff, merge, test your heart out of this:

git diff master
./run-tests.sh

Reducing work using pull request refs

The above works but several things can make your life worse:

What if you have many collaborators, each with their own forks? Adding all their forks and handling them separately becomes impractical.

What if you don't even have access to some of the forks and you can't checkout the source branch?

The solution to both the above issues it to use pull requests refs that some git servers provide. The procedure I'll show is supported by some git servers and varies slightly depending on the one you use. In the following I'll be covering how to fetch all pull requests on Stash (now called Bitbucket Server) and Github.

Do not fear the Refspecs

The first pre-requisite is to familiarize yourself with Refspecs. Refspecs are cool and you should not fear them. They are simple mappings from remote branches to local references, in other words a straight forward way to tell git "this remote branch (or this set of remote branches), should be mapped to these names locally, in this name space."

For example a command like:

git fetch +refs/heads/master:refs/remotes/origin/master

Will map the remote branch master on your origin remote to a local origin/master so that you can type:

git checkout origin/master

And refer still to that remote branch. The plus sign (+) in the definition is there to indicate that we want git to update the reference even if it's not fast-forward.

The way we use this to download all pull requests is to map how the remote repository stores the PR HEADs, and map them to a local name space for easy reference.

So provided you have an origin (or upstream) remote defined, here's what to do.

Note: As justly noted by several Stash (now called Bitbucket Server) developers the refs I'll demonstrate below are considered undocumented and private and could change anytime.

With that alias configured we can fetch a pull request with a simple (thanks inuit):

git spr 100

Conclusions

Hope you found this useful! In the end keeping tabs on the work of your peers or contributors is easy once you create a couple of simple aliases or add the proper refspecs to your .git/config. Happy to answer any questions you might have on Twitter at @durdn or @AtlDevtools.