What's the difference between git fetch and git pull?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
fetch downloads remote updates to your local remote-tracking branches without touching your work — safe inspection first. pull = fetch + merge (or rebase) into your current branch immediately. Prefer fetch then review then integrate for fewer surprises.
Detailed explanation
fetch syncs your view of the remote: updates origin/main and friends so git log origin/main, diffs, and comparisons reflect reality — while your local branches remain untouched, letting you inspect incoming work before committing to it. pull collapses that into one step: fetch followed by merging (default) or rebasing (pull --rebase) origin/current-branch into yours. Convenience costs control — surprise merges, unexpected conflicts mid-flow. Recommended rhythm on active teams: fetch, review what changed (git log HEAD..origin/main), then integrate deliberately — rebase for clean personal history, merge otherwise. Configure pull.rebase true if your team prefers rebase-by-default pulls. Related hygiene: prune stale tracking refs (fetch --prune) after deleted remote branches, and remember push failures often mean the remote advanced — fetch before force-pushing anything.
Example
git fetch origin # update remote refs only
git log HEAD..origin/main --oneline # preview incoming commits
git diff main...origin/main # see actual changes
git merge --ff-only origin/main # integrate if fast-forwardable
# One-shot equivalent:
git pull --rebase origin mainInterview tip
State the formula plainly — pull = fetch + merge — then demonstrate the inspect-before-integrate habit with the range-log command.
Common mistakes
- Believing pull never creates merge commits.
- Not knowing fetch alone never modifies working files.