How do y'all patch other people's PRs in your local dev env?

Scenario: you're assigned to review a pull request. It may have side-effects, so you want to build it locally to see it run for yourself. How do you do that?

Here's what I do:

• From my local git client I run git remote add <user> <git-url>. This creates a new remote (eg "origin" or "upstream") corresponding to the PR author's fork.
• I create branch off of whatever the PR is merging into, usually "master".
• I pull in the changes from the remote branch, git pull <user> <branch> where branch corresponds to whatever is shown in the PR.

Now my client should be synced to the contents of the PR and we're off.

I don't like that workflow. Can I borrow yours? What do other people do in this scenario?

I've heard about appending .patch to the PR URLs to get a patch file, but not quite sure how to streamline that. Help!

Comments

[Rob Hoelz]

For this, I have the following refspec in my projects' .git/config under [remote "origin"]:

fetch = +refs/pull/*/head:refs/pull/*

That way, whenever I git fetch, I have all of the PR commits under refs/pull/*, so if I want to try out the code for PR 123, I just need to git checkout pull/123 and go from there. You could also do something like +refs/pull/*/merge:refs/pr-merges/* if you want to check against the commits merging into the target branch, too!

[Nick Grimshaw]

Is this assuming that the remote is Github?

[Rob Hoelz]

Yes - I should have mentioned this is specific to GitHub! I don't know if other hosting platforms implement PRs the same way (ie. refs on the main repo), but if they do (or to find out if they do), you can do git ls-remote origin to list all of the refs on the remote and see if any pattern emerges from the output.

[Peter Storch]

I have this in my .zshrc (or .bashrc):

git_fetch_pull_request() {
    git fetch origin refs/pull/$1/head:pr/$1
    git checkout pr/$1
}
alias gpr='git_fetch_pull_request'

Then I can simply do gpr 115 to pull and checkout the PR locally.

[Ryan Kennedy]

I frequently cherry-pick single commits from other branches. If there are more than a couple of commits, I'll rebase (git rebase -i --autosquash, which I have aliased as git ri) and add their commits in with mine. Then once I'm satisfied, I'll rebase again and remove them.

[Ali Spittel]

I always click on "command line instructions" and copy paste to be totally honest

[Casey Brooks]

While I generally prefer using Git on the command-line, GitKraken makes the workflow for checking out PRs really easy. Under the list of branches, they will pull in the list of PRs on your repo, just double-click and it will set up the remote and check it out for you!

[Joshua Nelson ✨]

We actually have a very cool system that I hope to write about and share at some point – we have a static single page app, and we deploy each branch to a s3 bucket, and use a simple proxy to act like a staging / production environment.

This is cool because any reviewer can see exactly what the change is, and what it would act like in production.

You won't be able to play with the code though, so you might still need to take your approach (or one of the others mentioned) for playing with live code. Often though, I just want to test one scenario that I think of while reading the code, and the previews are useful for that.

[Adrian H]

What you are doing is called testing, manual testing.
You should request Automated Tests in the PR, and leave the testing to the QA or Product.

[Meghan (she/her)]

Make a new folder
git clone <url>
cd <directory>
git checkout <pr-branch>

[Yash Dusing]

I check the PR number and then 'git fetch upstream pull/PRNumber/head:branch_name'. Works like a charm