Git Fetch vs Git Pull (Explained Simply)

Both commands get new work from GitHub (or wherever your remote lives). The difference is what happens next:

git fetch downloads the new commits and stops. Your files and your branch don't change.
git pull downloads them and merges them into your current branch. Your files change.

In fact, git pull is literally git fetch followed by git merge (or git rebase, if configured).

What fetch actually updates

Your repository keeps a copy of what the remote looked like the last time you talked to it. These are remote-tracking branches, named like origin/main:

main — your local branch. Changes when you commit.
origin/main — your computer's snapshot of GitHub's main. Changes only when you fetch or pull.

git fetch updates origin/main (and every other origin/...) to match GitHub. Your main stays exactly where it was.

That's why git status can say "Your branch is up to date with 'origin/main'" when it isn't — it's comparing against a snapshot you haven't refreshed. Run git fetch first and it'll tell the truth.

Why fetch first?

Fetch lets you look before you leap:

git fetch

git log main..origin/main --oneline   # commits on GitHub you don't have
git diff main origin/main             # what they change

Then decide: merge them, rebase onto them, or deal with them later. Useful when you're mid-task, when a teammate (or an AI agent) has been pushing a lot, or when you want to review incoming changes. (How to read a diff)

After looking, bring them in:

git merge origin/main
# or
git rebase origin/main

When pull is fine

Most of the time, on a branch only you use or when you just want the latest, git pull is exactly right. Do it at the start of each session:

git switch main
git pull

Merge or rebase on pull

When your branch and the remote have both moved, pull has to combine them. You choose how:

git pull --rebase    # replay your commits on top: linear history
git pull --no-rebase # create a merge commit
git pull --ff-only   # only proceed if no combining is needed; otherwise stop

Set a default once:

git config --global pull.rebase true

--ff-only is the cautious choice: it never creates a merge commit or rewrites anything, and it fails loudly when branches have diverged, so you can decide. (Git rebase vs merge)

Pull with uncommitted changes

If your uncommitted changes touch the same files as the incoming commits, git refuses to pull. Commit them, or stash them:

git stash
git pull
git stash pop

(Git stash explained)

Quick reference

You want to	Run
See if there's anything new, safely	`git fetch` then `git status`
List incoming commits	`git log main..origin/main --oneline`
Get the latest and carry on	`git pull`
Get the latest, never auto-merge	`git pull --ff-only`
Update all remote branches, remove deleted ones	`git fetch --all --prune`

The summary

fetch downloads and updates origin/*; your work is untouched.
pull = fetch + merge (or rebase) into your current branch.
Fetch first when you want to see what's coming.
git status only knows about the remote as of your last fetch.

EasySpawn keeps your repository on a persistent server where you and Claude Code share the same branches, so there's less to fetch and nothing lost between sessions. See how it works or join the waitlist.

Git Fetch vs Git Pull: What's the Difference?