The first time someone asked me to review their pull request, I opened GitHub in one tab, Slack in another, and realized I had no idea how to actually run their code. I ended up manually cloning their fork, hunting for the branch name, and generally making a mess of my local repo. There had to be a better way.
Turns out there are two — and I've been using both for years now.
The Problem
The default workflow is awkward: message the author for their fork URL and branch name, or click through GitHub's UI to find it.
Method 1: Git Config (80% of My Reviews)
Add this to .git/config under [remote "origin"]:
fetch = +refs/pull/*/head:refs/remotes/github-pr/*fetch = +refs/pull/*/head:refs/remotes/github-pr/*
Now git fetch pulls all PRs:
* [new ref] refs/pull/1015/head -> github-pr/1015 * [new ref] refs/pull/1020/head -> github-pr/1020* [new ref] refs/pull/1015/head -> github-pr/1015 * [new ref] refs/pull/1020/head -> github-pr/1020
Checkout any PR:
git checkout github-pr/1015git checkout github-pr/1015
You're now on the exact commit from the PR. Yes, it's a detached HEAD. Yes, that's mildly annoying if you want to push changes. But for reading code and running tests — which is most of my reviews — I don't care. It works on any machine with Git, including ancient servers where installing new tools isn't an option.
One gotcha nobody mentions: this changes your default fetch behavior. Every plain git fetch now pulls all PR refs alongside your branches. That said, you can still fetch selectively on the command line — git fetch origin main works fine. For repos with 20-50 open PRs, the extra refs are barely noticeable. For larger ones, prepare for slower fetches when you fetch everything.
Method 2: GitHub CLI (When I Need Power)
Sometimes you need more. Maybe you want to push fixes back to the PR — fix a typo, push it, they merge, everyone's happy. Or maybe you want proper branch tracking.
Install the GitHub CLI, authenticate once with gh auth login, then:
gh pr checkout 1015gh pr checkout 1015
Unlike the git config method (which leaves you in detached HEAD), this checks out a proper named branch with remote tracking set up. Push works because gh configured the upstream for you.
I also use gh pr list to scan open PRs without loading GitHub's increasingly slow interface. Then I checkout the interesting ones.
The Annoying Part
It's another tool to install. Another thing that can break when SSH'd into a server. Another auth token to manage. When gh works, it's great. When it doesn't, you're debugging OAuth flows instead of reviewing code.
Auth tokens expire. When they do, you get cryptic errors like "HTTP 401" instead of a helpful message. And if you use multiple GitHub accounts, gh sometimes picks the wrong one.
My Actual Workflow
Quick review — just reading and testing:
git fetch git checkout github-pr/420 go test ./... git checkout maingit fetch git checkout github-pr/420 go test ./... git checkout main
Review where I need to fix something:
git checkout main # start clean gh pr checkout 420 --branch review-420 # ... fix the bug ... git commit -am "fix: handle nil pointer" git push # pushes to their PR automatically gh pr review 420 --approvegit checkout main # start clean gh pr checkout 420 --branch review-420 # ... fix the bug ... git commit -am "fix: handle nil pointer" git push # pushes to their PR automatically gh pr review 420 --approve
The CLI shines when you're making changes. For just reading code? Overkill.
The Hidden Cost Nobody Mentions
Here's an edge case I hit once: the git config method fetches ALL PRs on every plain fetch. If you're in a repo with 500 open PRs, that's a lot of refs. Your git fetch slows down. git branch -a becomes basically unreadable.
In that case, use gh. It checks out only what you need.
For normal repos with 20-50 PRs? Honestly, who cares. Fetch them all.
Comments