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=.

How to Squash Commits with Git

Part of my Git workflow at Automattic includes getting a pull request going as soon as possible.

I find this workflow useful as I am learning the code base for the latest version of, which is completely different from any codebase I have touched before. Because of this, I try to commit often so that I can get feedback and collaborate with my coworkers.

And while committing often is great to get feedback in a pull request, I tend to like to squash all of the commits into one before I merge my pull request into master.

How I Squash Commits with Git

The first few times I squashed commits with Git were very nerve wracking as I was worried about nuking my changeset. But, as I have worked more with Git in a team setting, I have become very comfortable with these following steps:

  1. Get merge base git merge-base my-branch-name master
  2. Rebase git rebase --interactive {hash from merge base}
  3. Change pick to squash for all but first commit

Although I have grown comfortable with the above commands, I find that I sometimes still refer to this awesome article from edX about rebasing pull requests.

If you find you need a bit more explanation for how to squash commits with Git, I’d recommend giving that article a read.

Github Two-Factor Authentication Failed For HTTPS

About two months ago I first switched to GitHub’s two-factor authentication. Later that day, when I went to push for the first, I had an authentication error and my push failed. I didn’t want to mess with the configuration that day, so I decided to turn off two-factor authentication on GitHub.

Another Go at Two-Factor Authentication on GitHub

After a new career move forced that I lock down my computer and my online identities like Fort Knox, I had no choice but to figure out how to get GitHub two-factor authentication working. Yet again, after I configured two-factor authentication on GitHub I had issues pulling from private repositories and pushing/pulling to any repository. So, after digging into the GitHub two-factor authentication blog post on GitHub, I came across this:

If you are using SSH for Git authentication, rest easy: you don’t need to do anything. If you are using HTTPS Git, instead of entering your password, enter a personal access token. These can be created by going to your application settings page.

The Solution is Simple

Continue reading “Github Two-Factor Authentication Failed For HTTPS”

Remove Files from Git After Adding/Updating .Gitignore

I recently inherited a project from a beginning developer. After inheriting the project I realized that, while the developer was using Git to source control the project, the developer had completely forgot to add a .gitignore.

This meant that I now needed to add a .gitignore file as well as remove files from git that were tracked that shouldn’t have been tracked.

This isn’t usually a big deal when ignoring a single file or two — The command to remove a single file is:

git rm --cached <file>

But, since we use Grunt and Sass for our web development projects, there were a ton of files within node_modules  and .sass_cache  as well as .DS_Store files throughout.

To get around writing multiple commands to ignore all of these files and un-track them, I did this:

git rm -r --cached .
git add -A
git commit -am 'Removing ignored files'

The first command will un-track all files in your git repository.

The second command will then add all of the files in your git repository, except those that match rules in your .gitignore. Thus, we have un-tracked several files with just two commands.

Then the last command is to commit the changes, which will just be removed files.