How can I check out a GitHub pull request with git?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Checking out a GitHub pull request locally lets you review, build, and test the proposed changes as if they were a normal branch. The important detail is that a pull request is not magic in Git itself. On GitHub, it is backed by refs that you can fetch with ordinary Git commands. Once you know the pull request number, you can bring the branch into your local repository cleanly.
Fetch the Pull Request by Number
GitHub exposes pull request heads under refs/pull/<number>/head. That means you can fetch a pull request directly without guessing the contributor's remote branch name.
This does two things:
- Fetches pull request 123 from
origin. - Creates a local branch named
pr-123pointing to that pull request head.
This is the most direct and portable approach when all you need is the code from the pull request.
Use checkout on Older Git Versions
If the local Git version predates git switch, use git checkout instead.
The result is the same. The branch name is local, so you can choose any naming convention that fits the repository.
Fetch the Merge Ref When You Need the Merged Result
Sometimes you do not want the raw pull request branch. You want the merge candidate that GitHub shows in the UI. GitHub exposes that separately.
Use this when the real question is “what happens if this PR is merged into the base branch right now.” That is especially useful for reproducing CI behavior or merge-specific test failures.
Check Out a Pull Request from a Fork Manually
If you know the contributor's fork and branch, you can also add their remote and fetch it like any other branch.
This approach is useful when you need to inspect the contributor's branch history directly or keep their fork around for repeated collaboration. For one-off review, the refs/pull method is usually simpler.
Keep the Review Branch Disposable
A pull request checkout branch is usually a temporary working branch. Once the review is done, you can delete it locally.
That keeps the local branch list clean and prevents old review branches from accumulating.
Understand What You Actually Fetched
There are two important possibilities:
- The PR head, meaning the contributor's proposed branch tip.
- The PR merge ref, meaning GitHub's merge test result against the base branch.
Those are not always the same commit. If review comments refer to the contributor's exact changes, fetch the head. If build behavior depends on the base branch integration, fetch the merge ref.
Use GitHub CLI If the Team Already Has It
If the repository already uses GitHub CLI, the ergonomic command is even shorter:
That is convenient, but it is a GitHub-specific helper layered on top of the same basic idea. Knowing the raw Git commands is still useful because they work anywhere GitHub refs are available and do not require extra tooling.
Common Pitfalls
- Fetching the pull request head when you actually needed the merge ref.
- Forgetting to create a local branch name and ending up in a detached HEAD state.
- Assuming a pull request exists as a normal local Git concept instead of as GitHub-managed refs.
- Leaving many old review branches around and cluttering the local repository.
- Confusing the contributor's fork branch with the GitHub
refs/pullshortcut and using the wrong workflow for the review goal.
Summary
- A GitHub pull request can be fetched directly by number using
pull/<number>/head. - Use
git switchorgit checkoutto move onto the fetched local review branch. - Fetch
pull/<number>/mergewhen you need the merge candidate rather than the raw PR branch. - Add the contributor's remote only when you specifically need fork-level branch access.
- Treat PR checkout branches as disposable review branches and clean them up after use.

