GitHub
pull request
git
version control
software development

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.

bash
git fetch origin pull/123/head:pr-123
git switch pr-123

This does two things:

  1. Fetches pull request 123 from origin.
  2. Creates a local branch named pr-123 pointing 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.

bash
git fetch origin pull/123/head:pr-123
git checkout pr-123

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.

bash
git fetch origin pull/123/merge:pr-123-merge
git switch pr-123-merge

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.

bash
git remote add contributor https://github.com/example-user/project.git
git fetch contributor feature-branch
git switch -c pr-feature contributor/feature-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.

bash
git switch main
git branch -D pr-123

That keeps the local branch list clean and prevents old review branches from accumulating.

Understand What You Actually Fetched

There are two important possibilities:

  1. The PR head, meaning the contributor's proposed branch tip.
  2. 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:

bash
gh pr checkout 123

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/pull shortcut 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 switch or git checkout to move onto the fetched local review branch.
  • Fetch pull/<number>/merge when 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.

Course illustration
Course illustration

All Rights Reserved.