Checking Out a Developer's Branch to Test It

Learning Objectives

By the end of this lesson you will be able to:

Get a developer's branch onto your machine and run it
Fetch a Pull Request branch even from a fork
Keep your test branch up to date as the developer pushes changes
Clean up afterwards without leaving debris

The Skill That Changes the Job

Everything so far has been preparation for this. A PR is open, the CI is green, and the question is whether it actually works.

git fetch origin
git switch feature/PAY-4102-new-auth-flow

That is it. Git sees a remote branch of that name, creates a local branch tracking it, and checks it out:

branch 'feature/PAY-4102-new-auth-flow' set up to track 'origin/feature/PAY-4102-new-auth-flow'.
Switched to a new branch 'feature/PAY-4102-new-auth-flow'

You now have the developer's exact code. Install, build, run:

npm ci                              # dependencies exactly as the lockfile says
npm run build
npm test
npm start

You are testing the change before it enters main. That is the whole point of the module.

The older, more explicit form does the same thing, and you will see it in documentation:

git checkout -b feature/PAY-4102-new-auth-flow origin/feature/PAY-4102-new-auth-flow

Before You Switch

Two things, every time.

Fetch first. If you haven't fetched, the branch may not exist in your picture of the server yet — Lesson 6.2's most common confusion.

Have a clean working tree. Uncommitted changes travel with you and will contaminate what you are about to test. Commit them, or stash them — Module 4 exists for exactly this moment.

git status                          # clean?
git stash push -u -m "my fixture work"
git fetch origin
git switch feature/PAY-4102-new-auth-flow

Branches From a Fork

Open-source projects, and many companies, take contributions from forks — a separate copy of the repository. The branch is not on origin at all, so git switch <branch> will not find it.

GitHub exposes every PR under a special reference. Fetch it by number:

git fetch origin pull/402/head:pr-402
git switch pr-402

That reads: fetch the head of PR #402 from origin, create a local branch called pr-402, then switch to it. 402 is the PR number from the URL.

GitLab uses a slightly different path:

git fetch origin merge-requests/402/head:mr-402
git switch mr-402

If your team uses the GitHub CLI, it wraps all of this:

gh pr checkout 402

One command, works for forks and same-repo branches alike. Worth installing if you check out PRs regularly.

Staying Current While You Test

The developer pushes a fix in response to your comment. You need the new version:

git fetch origin
git status                          # anything of yours in the way?
git pull                            # fast-forward to the new commits

git pull is appropriate here — you have no commits of your own on this branch, so it will simply fast-forward.

Confirm you have what you expect:

git log --oneline -3

Compare the commit ID against the one shown at the top of the PR page. If they match, you are testing exactly what the reviewers are reading.

Testing Against Current `main`

A PR branch may have been created a week ago. It might pass on its own and still break once merged, because main has moved.

To test the merged result before it exists:

git switch feature/PAY-4102-new-auth-flow
git fetch origin
git merge origin/main               # simulate the merge locally
npm test

If that surfaces a problem, it is one of the most valuable things you can report — a defect that does not exist in either branch alone and would appear only after merging.

Undo the simulation when you are finished:

git reset --hard origin/feature/PAY-4102-new-auth-flow

That restores the branch to exactly the server's version. Since you had no work of your own here, nothing is lost.

Cleaning Up

After the PR merges:

git switch main
git pull
git branch -d feature/PAY-4102-new-auth-flow
git fetch --prune

-d will succeed because the branch is now merged. Prune removes the remote-tracking reference the platform deleted.

And restore whatever you were doing:

git switch test/my-fixture-work
git stash pop

Pro Tip: Write the result in the PR itself, not only in the ticket: "Checked out at d4e5f6a, ran the auth suite — 11/11 green. Also verified expired-token manually against a local Postgres." It tells reviewers exactly what was covered, at exactly which commit, and it is the clearest possible evidence that QA was here.

Key Takeaways

git fetch origin then git switch <branch> is all it takes to run a developer's code
Always fetch first and start from a clean working tree; stash anything of your own
Fork PRs need git fetch origin pull/<n>/head:<local-name>, or gh pr checkout <n>
git pull is safe on a PR branch you have not committed to — it just fast-forwards
Merging origin/main into the PR branch locally reveals defects that appear only after merge
Report the commit ID you tested at; it makes your result verifiable