How to Git Fetch a Branch (and Why It Matters for Security)

To git fetch a specific branch, run git fetch origin <branch-name>, which downloads that branch's latest commits into your local repository without touching your working directory or merging anything. This is the command's whole appeal: it brings remote changes into view so you can inspect them before deciding what to do. That inspect-before-integrate gap is not just a convenience — it's a security control, and understanding it changes how you handle pull requests, forks, and any code you didn't write yourself.

The basic command

Fetching a single branch is direct:

git fetch origin feature/login-refactor

This contacts the remote named origin, downloads the commits on feature/login-refactor, and updates your remote-tracking reference origin/feature/login-refactor. Your current branch, your working files, and your staged changes are all left exactly as they were. Nothing is merged.

To fetch everything a remote has:

git fetch origin

And to fetch from every configured remote at once:

git fetch --all

A useful companion flag is --prune, which deletes local remote-tracking references for branches that have been removed on the remote, so your git branch -r list doesn't slowly fill with ghosts:

git fetch --prune origin

Fetch versus pull: the distinction that matters

The single most important thing to understand is that git pull is git fetch followed by git merge (or git rebase, depending on your config). Pull downloads and integrates in one step. Fetch only downloads.

That difference is exactly where the security value lives. When you git pull, remote changes land in your working tree immediately — you're running, building, and potentially executing that code before you've read a line of it. When you git fetch, you get a checkpoint: the commits are local, but nothing has been applied. You can now inspect what arrived.

# See what changed before integrating
git fetch origin main
git log --oneline HEAD..origin/main
git diff HEAD origin/main

Only after reviewing do you decide to git merge origin/main or git rebase origin/main. For your own well-known branches this ceremony is overkill. For code from a fork, an external contributor, or an automated dependency-update bot, that pause is worth taking.

Fetching and checking out a pull request branch

A common task: someone opens a PR from their fork and you want to run it locally. Fetch it into a local branch you can check out:

git fetch origin pull/42/head:pr-42
git checkout pr-42

On GitHub, the pull/<number>/head ref exposes any PR's head commit even when it lives on a fork you can't otherwise name. The :pr-42 part creates a local branch from it. Now you can read the diff, run the test suite in a sandbox, and scan the dependencies before you trust it.

This is the moment to be deliberate. A malicious pull request can do more than introduce a subtle logic bug — it can add a dependency with a compromised install script, modify a CI workflow to exfiltrate secrets, or slip a backdoor into a build tool. Fetching without checking out or building keeps the code inert until you've looked.

Why fetch-then-review is a security habit

Supply-chain attacks increasingly target the developer's own machine and CI environment, not just production. Running unreviewed code from a fork can trigger install-time scripts, and a modified GitHub Actions workflow in a PR can run with access to repository secrets if your CI is misconfigured. The git fetch step gives you a place to intervene before any of that executes.

Concretely, after fetching an external branch, a cautious reviewer:

• reads the diff of every changed file, with extra attention to package.json, lockfiles, CI workflow YAML, and any build scripts;
• checks whether new dependencies were added, and whether they're real packages at expected versions rather than typosquats;
• runs any build or test only inside a disposable, secret-free sandbox for untrusted contributions.

That last point deserves emphasis: the newly added dependency is where the real risk usually hides, not the visible application code. A software composition analysis tool such as Safeguard can scan a fetched branch's dependency tree and flag a newly introduced transitive CVE or a suspicious package before you ever run npm install. Our SCA overview covers how that fits into a review workflow, and the Academy has a walkthrough on vetting external contributions.

Fetch options worth knowing

A few flags make git fetch more precise and safer:

• git fetch --dry-run origin shows what would be fetched without changing anything — useful for confirming a remote's state.
• git fetch --depth=1 origin main does a shallow fetch of just the latest commit, handy for large repos or CI where full history isn't needed.
• git fetch origin +refs/heads/*:refs/remotes/origin/* (the default refspec) can be narrowed to fetch only specific branch patterns, reducing what you download from a remote you don't fully trust.

For CI pipelines that check out untrusted code, combining a shallow fetch with an isolated runner limits both the data transferred and the blast radius if something goes wrong.

FAQ

What's the difference between git fetch and git pull?

git fetch downloads remote commits into your local repository without merging them into your current branch, leaving your working tree untouched. git pull does the same fetch and then immediately merges or rebases those changes in. Fetch gives you a chance to review before integrating; pull skips that pause.

How do I git fetch just one branch?

Run git fetch origin <branch-name>. This downloads only that branch's commits and updates the corresponding remote-tracking reference, without affecting any other branch or your working directory.

How do I fetch a pull request from a fork?

Use git fetch origin pull/<number>/head:<local-branch> on GitHub, then git checkout <local-branch>. This pulls the PR's head commit into a local branch you can inspect and test, even when it originates from a fork.

Is fetching code safer than pulling it?

Fetching is safer for untrusted sources because it downloads without executing or building anything, giving you a checkpoint to review the diff, inspect new dependencies, and scan for vulnerabilities before you integrate. For your own trusted branches, the distinction matters less.