Introduction

git fetch downloads new objects and updates remote-tracking refs without changing your working tree. git pull does a fetch and then integrates the result into your current branch. Knowing the difference is one of the biggest steps from novice to confident Git user.

Fetching

git fetch                  # default remote (usually origin)
git fetch origin
git fetch --all
git fetch --prune          # delete refs for branches deleted on server
git fetch origin main      # only one branch

After a fetch, inspect what changed:

git log HEAD..origin/main --oneline
git diff HEAD origin/main

Pulling

git pull is shorthand for fetch followed by either merge or rebase. Choose the strategy:

git pull                          # uses pull.rebase config
git pull --rebase
git pull --ff-only                # refuse if not fast-forward
git pull origin main

Configuring default behaviour

git config --global pull.rebase false   # merge (classic default)
git config --global pull.rebase true    # rebase
git config --global pull.ff only        # only fast-forward
git config --global fetch.prune true

Since Git 2.27 a bare git pull warns if no strategy is configured.

Fetch vs pull, when to use which

• Use fetch when you want to look before integrating.
• Use pull --ff-only when you simply want to catch up on a shared branch.
• Use pull --rebase when working on a topic branch you have not pushed.
• Avoid plain pull on long-lived shared branches; merge commits multiply.

Inspecting upstream

git status
# On branch main
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

This message comes from comparing HEAD to the cached origin/main; run git fetch first to make it accurate.

Fetching pull requests

Most Git hosts expose pull or merge request branches as special refs you can fetch into your clone for review. For GitHub, add a refspec:

git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
git fetch
git switch -c review/123 origin/pr/123

For GitLab the equivalent path is refs/merge-requests/*/head. With this configured, every git fetch grabs all open PRs locally, ready for inspection without leaving your terminal.

Common mistakes

Running git pull with uncommitted changes and getting an unexpected merge commit on top of dirty work. Stash or commit first. Forgetting that git status's "behind" count is only as fresh as the last fetch; if no one has fetched in a week, that count lies. Using git pull --rebase on a branch other people have based work on rewrites their base; rebase only on private branches. And finally, never use git fetch <refspec> with a custom refspec unless you understand it; an accidental colon (main:main) overwrites your local main.