DEV Community

Asaduzzaman Pavel
Asaduzzaman Pavel

Posted on • Originally published at iampavel.dev

GitHub PR Checkout: Two Methods That Actually Work

#git #workflow #github #codereview

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 with Code Review

GitHub's web interface works for small diffs. But when you need to actually run the code — test that endpoint, verify the UI fix, debug why tests fail — you need the PR locally.

The default workflow is awkward: message the author for their fork URL and branch name, or click through GitHub's UI to find it. Both are slower than they should be.

What I wanted was simple: type the PR number, get the code.

Method 1: Git Config (80% of My Reviews)

Add this to .git/config under [remote "origin"]:

fetch = +refs/pull/*/head:refs/remotes/github-pr/*
Enter fullscreen mode Exit fullscreen mode

Now git fetch pulls all PRs:

 * [new ref]   refs/pull/1015/head -> github-pr/1015
 * [new ref]   refs/pull/1020/head -> github-pr/1020
Enter fullscreen mode Exit fullscreen mode

Checkout any PR:

git checkout github-pr/1015
Enter fullscreen mode Exit fullscreen mode

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.

Actually, the detached HEAD is kind of a feature sometimes. It stops me from accidentally committing to someone else's PR when I'm just exploring.

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 1015
Enter fullscreen mode Exit fullscreen mode

This sets up proper branch names, remote tracking, and handles forks automatically. 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.

Also, gh auto-updated once and broke my shell integration for two days. Not fun when you're trying to ship.

My Actual Workflow

Quick review — just reading and testing:

git fetch
git checkout github-pr/420
go test ./...
git checkout main
Enter fullscreen mode Exit fullscreen mode

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 --approve
Enter fullscreen mode Exit fullscreen mode

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

Meta description: Learn how to checkout GitHub pull requests for local testing. Two practical methods: a quick git config hack for fast reviews, and GitHub CLI when you need to push changes back.

Top comments (0)