Reviewing PRs Locally: git fetch + Checkout a PR Branch

GitHub's web-based diff view (covered in the code review lesson) is sufficient for most reviews, but sometimes you genuinely need to run the code — testing an interactive feature, debugging an issue that only appears when actually executing the code, or exploring a large change more comfortably in your own editor. This lesson covers pulling a pull request's exact branch down to your local machine.

Learning Objectives

Fetch a pull request's branch, whether from the same repository or a fork, to your local machine.
Check out that branch locally to run and test the proposed changes.
Use GitHub's official CLI tool as a simpler alternative to manual fetch commands.
Return safely to your own work after reviewing a PR branch locally.

Key Terms to Know Before Reviewing a PR Locally

PR branch: The actual Git branch underlying a pull request, which can be fetched and checked out locally like any other branch, whether it lives in the same repository or a contributor's fork.
Refspec: A Git configuration pattern specifying how remote references map to local ones, used here to fetch a pull request's branch using GitHub's special pull request reference format.
GitHub CLI (gh): GitHub's official command-line tool, which includes a dedicated, simplified command for checking out a pull request's branch locally.
pull/<number>/head: A special reference GitHub maintains for every pull request, usable with git fetch to retrieve that PR's exact branch content, even from a fork you haven't added as a separate remote.

How Reviewing a Pull Request Locally Actually Works

If a pull request's branch exists in a repository you already have as a remote (for example, a teammate's feature branch on a shared repository, rather than a fork), reviewing it locally is straightforward — it's just a normal branch:

```
git fetch origin
git switch feature/dark-mode
```

The more interesting case is a pull request from a **fork** — very common for external, open-source contributions (earlier lessons this module) — where the branch doesn't exist as a local reference on your `origin` remote at all, since it lives on the contributor's own fork. GitHub maintains a special reference for every pull request, regardless of whether it comes from a fork, in the form `pull/<number>/head`, which can be fetched directly without needing to add the contributor's fork as a separate remote:

```
git fetch origin pull/87/head:pr-87
git switch pr-87
```

This fetches PR #87's exact branch content and creates a new local branch named `pr-87` (you can choose any local name you like after the colon) pointing to it, which you can then check out and explore exactly like any other local branch — running it, testing it, or examining its files directly in your editor.

For a simpler, more memorable alternative, **GitHub's official CLI tool (`gh`)** provides a dedicated command specifically for this exact purpose:

```
gh pr checkout 87
```

This single command handles the equivalent fetch-and-checkout sequence automatically — including correctly handling the fork case without needing to manually construct the `pull/<number>/head` refspec — and is generally the recommended approach for anyone who has the GitHub CLI installed, since it removes the need to remember Git's more verbose manual syntax.

Once you're done exploring a PR branch locally — having run its tests, tried out its behavior, or reviewed its code comfortably in your own editor — returning to your own work is exactly like switching between any other branches (Module 3):

```
git switch main
```

This entire local-review workflow is a valuable complement to GitHub's web-based review tools (previous lessons), not a replacement for them — inline comments and suggested changes still happen through the web interface, but having pulled the code down locally first lets you form a more informed, hands-on opinion before leaving that feedback.

Fetching and Checking Out a PR Branch: Visual Walkthrough

Draw two parallel flows. LEFT labeled 'Same-repository PR branch': 'git fetch origin' → 'git switch feature/dark-mode' (branch already exists as a normal remote reference). RIGHT labeled 'Fork-based PR branch (no direct remote)': 'git fetch origin pull/87/head:pr-87' → 'git switch pr-87' (creates a new local branch from GitHub's special PR reference, no fork remote needed). Below both, show a shortcut box: 'gh pr checkout 87 — does the equivalent of either flow automatically, using the GitHub CLI.' Add a final arrow: 'git switch main — return to your own work when done reviewing.'

Methods for Reviewing a PR Locally: Quick Reference Table

Method	Command	Best For
Same-repository branch	git fetch origin && git switch <branch-name>	PRs from teammates on a shared repository
Fork-based branch (manual)	git fetch origin pull/<N>/head:pr-<N> && git switch pr-<N>	PRs from external contributors' forks, no CLI installed
GitHub CLI (recommended)	gh pr checkout <N>	Any PR — simplest, handles forks automatically
Returning to your own work	git switch main (or your usual branch)	After finishing local review/testing

Fetching and Checking Out a PR: Command Syntax and Examples

# Reviewing a PR from a teammate's branch on the same repository
git fetch origin
git switch feature/dark-mode

# Reviewing a PR from an external contributor's FORK (manual method)
git fetch origin pull/87/head:pr-87
git switch pr-87

# Reviewing the same fork-based PR using GitHub CLI (simpler, recommended)
gh pr checkout 87

# After testing/reviewing locally, return to your own work
git switch main

Breaking Down the Local PR Review Example

The first block handles the simpler case — a PR branch already available as a normal remote reference. The second block demonstrates the special `pull/87/head:pr-87` refspec, which retrieves PR #87's exact content directly from GitHub, regardless of whether it originates from a fork, without needing to add that contributor's fork as a separate remote first. The third block shows the equivalent, much simpler `gh pr checkout 87` command, achieving the same result with GitHub's official CLI tool. The final `git switch main` demonstrates safely returning to your own ongoing work once local exploration of the PR is complete.

How Local PR Review Is Used on Real Engineering Teams

Reviewers on projects with complex, hard-to-test-via-diff-alone changes (like UI interactions, performance-sensitive code, or anything requiring actually running the application) routinely check out a PR branch locally before approving.
Maintainers of popular open-source projects frequently use gh pr checkout specifically because it elegantly handles the very common case of reviewing contributions from many different external forks without manually managing dozens of separate fork remotes.
Security-focused code review sometimes specifically requires running proposed changes in an isolated local (or sandboxed) environment before approval, making local checkout a mandatory review step rather than an optional convenience.
Debugging a reported issue in a pull request that only manifests when the application is actually running (not visible from a static diff) is one of the most common reasons a reviewer reaches for a local checkout.

Reviewing PRs Locally Interview Questions and Answers

Q1. How would you check out a pull request's branch locally if it comes from a contributor's fork, without adding that fork as a separate remote?

Use GitHub's special pull request reference with git fetch, in the form git fetch origin pull/<PR-number>/head:<local-branch-name>, followed by git switch <local-branch-name>. This retrieves the PR's exact branch content directly, regardless of which fork it originates from.

Q2. What does the GitHub CLI command gh pr checkout <number> do?

It performs the equivalent of fetching and checking out a pull request's branch locally in a single, simplified command, correctly handling both same-repository and fork-based PRs automatically, without needing to manually construct Git's more verbose refspec syntax.

Q3. Why might a reviewer choose to check out a pull request locally rather than relying solely on GitHub's web-based diff view?

Some situations genuinely require running the code — testing an interactive feature, debugging behavior that only appears during actual execution, or exploring a large, complex change more comfortably within a full local editor — none of which a static web diff view alone can fully substitute for.

Reviewing PRs Locally Quiz: Test Your Understanding

1. What special Git reference does GitHub maintain for every pull request, usable to fetch its exact branch content?

main/head
pull/<number>/head
review/<number>
origin/pr

Answer: B. pull/<number>/head

Explanation: GitHub maintains a pull/<number>/head reference for every pull request, which can be fetched directly with git fetch, regardless of whether the PR originates from the same repository or an external fork.

2. What does the GitHub CLI command gh pr checkout 87 accomplish?

Deletes pull request #87
Fetches and checks out pull request #87's branch locally in one simplified step
Merges pull request #87 automatically
Lists all open pull requests

Answer: B. Fetches and checks out pull request #87's branch locally in one simplified step

Explanation: gh pr checkout is a dedicated GitHub CLI command that performs the equivalent fetch-and-switch sequence automatically, correctly handling fork-based PRs without manual refspec syntax.

3. Why might a reviewer need to check out a pull request locally rather than only reviewing its diff on GitHub's website?

GitHub's website cannot display diffs at all
To actually run, test, or debug the proposed changes, which a static diff view alone cannot fully substitute for
Local checkout is required before any comment can be left
It permanently merges the PR

Answer: B. To actually run, test, or debug the proposed changes, which a static diff view alone cannot fully substitute for

Explanation: Certain review needs — like testing interactive behavior or debugging something that only appears during execution — genuinely require running the code locally, beyond what a web-based diff view can provide.

Common Mistakes When Reviewing a PR Locally

Attempting to check out a fork-based PR branch as if it were a normal remote branch, without realizing the special pull/<number>/head reference (or GitHub CLI) is needed since the fork isn't a configured remote.
Forgetting to switch back to your own branch after locally reviewing a PR, and accidentally continuing to work on the PR's branch instead.
Not installing or using the GitHub CLI when it would meaningfully simplify a workflow that otherwise requires remembering Git's more verbose manual refspec syntax.
Assuming local checkout replaces the need for GitHub's web-based review tools, rather than treating it as a complement used alongside inline comments and suggested changes.

Reviewing PRs Locally: Exam-Ready Quick Notes

Same-repo PR branch: git fetch origin, then git switch <branch-name> — works like any normal branch.
Fork-based PR branch: git fetch origin pull/<N>/head:<local-name>, then git switch <local-name>.
GitHub CLI shortcut: gh pr checkout <N> — handles both cases automatically, simpler syntax.
Always switch back to your own branch (e.g., git switch main) after finishing local review.

Reviewing PRs Locally: Key Takeaways

Local PR review complements GitHub's web-based tools for situations that genuinely require running or deeply exploring the actual code.
GitHub's special pull/<number>/head reference makes it possible to fetch any PR's branch directly, even from a fork, without adding it as a separate remote.
The GitHub CLI's gh pr checkout command significantly simplifies this workflow for anyone who has it installed.

Frequently Asked Questions About Reviewing PRs Locally

Q1. How do I check out a pull request's branch on my own machine?

If the branch is on the same repository, use git fetch origin followed by git switch <branch-name>. If it's from a contributor's fork, use git fetch origin pull/<PR-number>/head:<local-branch-name> followed by git switch <local-branch-name>, or simply use gh pr checkout <PR-number> if you have the GitHub CLI installed.

Q2. Why would I need to check out a pull request locally instead of just reviewing it on GitHub's website?

Some review needs genuinely require running the actual code — testing interactive features, debugging behavior that only appears during execution, or exploring a large, complex change more comfortably in your own editor — which a static web diff view alone can't fully substitute for.

Q3. What is the pull/<number>/head reference in Git?

It's a special reference GitHub maintains for every pull request, letting you fetch that PR's exact branch content directly with git fetch, regardless of whether it originates from the same repository or an external contributor's fork, without needing to add that fork as a separate remote.

Q4. What does gh pr checkout do?

It's a GitHub CLI command that fetches and checks out a pull request's branch locally in a single, simplified step, automatically handling both same-repository and fork-based PRs without requiring you to remember Git's more verbose manual syntax.

Q5. How do I get back to my own work after reviewing a PR branch locally?

Simply switch back to your own branch, such as git switch main, exactly as you would when switching between any other branches.

Summary

While GitHub's web-based diff view handles most review needs, some situations — testing interactive behavior, debugging something that only appears when actually running the code, or exploring a large change more comfortably in a local editor — genuinely require checking out a pull request's branch locally. For a PR branch already available as a normal remote reference (same repository), this is as simple as `git fetch origin` followed by `git switch <branch-name>`. For a PR from an external contributor's fork, GitHub's special `pull/<number>/head` reference allows fetching that exact branch content directly with `git fetch origin pull/<N>/head:<local-name>`, without needing to add the fork as a separate remote. GitHub's official CLI tool offers an even simpler alternative, `gh pr checkout <number>`, handling both cases automatically. This local-review workflow complements, rather than replaces, GitHub's web-based inline comments and suggested changes covered in the earlier code review lesson.