Git checkout non-origin remote pull request

I don’t often review pull requests that come from non-origin remotes. This is largely because Automattic tends to create pull requests in the root repository. So, when I reviewed a pull request from an open source contributor today, I found myself wandering if there was a simple way to checkout the pull request locally for testing.

I knew that I could add a new remote, fetch from the new remote, and then checkout the pull request. But, my lazy developer brain figured there was an easier way. 😄

So, I asked my fellow Automatticians if they had any tips/tricks and I got a few good ones.

First, and probably the best solution, is to use the Github’s CLI tool. Once you’ve installed that, you can then checkout a pull request locally with something like:

gh pr checkout {<number> | <url> | <branch>}

But, if you’re relatively happy with your git flow and are looking for a little helper for this specific case, then you may be interested in this blog post by Scott Lowe. In that post, Scott shares a tip for fetching the branch from the non-origin remote to your local machine in a single command:

git fetch origin pull/1234/head:pr-1234

In my testing, this worked very well for me. But, I wanted to be a bit lazier. So, I ended up throwing that command in a shell function that expects the pull request number as an argument and then:

  1. Fetches the branch from the non-origin remote
  2. Checks out the branch from the non-origin remote

That function looks like this:

function gcopr() {
	$( git fetch origin pull/"$1"/head:pr-"$1" )
	$( git checkout pr-"$1" )

I’ve got this function in my ~/.oh-my-zsh/custom` directory and I use it like this:

gcopr 42940

Prefilling Github Issues

Earlier today, I created an internal “Call for testing” post where I essentially asked other Automatticians to break a piece of functionality that I intend to launch.

To help with the testing process, I included a link to a pre-filled Github issue. For the most part, pre-filling the issue with a label, milestone, etc. was pretty easy, but there were a few gotchas.

So, below I’ll break down how to prefill as much of the Github issue form as possible.

Creating issues

First of all, you should know that to create an issue for a repository, that you would go to a URL like:{owner]/{repo_name}/issues/new

As long as you’re logged in, when you go to the above URL, you’ll be shown a form to create a new issue. And since the new issue form is in the same place for each repo, you can share this link (and even prefill it) to make life a little bit easier for those that are using and testing your software.

The secret formula


In the above screenshot, you can see that there are 5 pieces of information that can be filled out in a new Github issue. These are:

  • Title
  • Description
  • Labels
  • Milestone
  • Assignee

Now, to prefill these all we need to do is add parameters to the query string. Here’s an example:[]=People%20Management&labels[]=[Type]%20Bug&title=People:&milestone=People%20Management:%20m6&assignee=ebinnion&body=This%20is%20a%20prefilled%20issue

Note that the values in the URL above are also URL encoded.


In the above link note that there is no &amp;description. That’s because Github fills the description with whatever is in the &amp;body parameter.

Lastly, note the use of labels[]= when assigning multiple labels. If you want to just add one label, you should be able to just do labels=.