git fetch updates your knowledge of GitHub — not your files

A mental-model fix that clears up most “but GitHub says something different” confusion.

The realization

git status doesn’t talk to GitHub. It only compares your local files against what your machine last heard about the remote. That “last heard” snapshot only updates when you run git fetch (or a command that fetches, like git pull).

So if a teammate pushed 5 minutes ago and you haven’t fetched, your git status still cheerfully says “up to date” — because it’s up to date with old news.

The vocabulary

Why fetch is safe and pull isn’t (always)

git fetch        # safe: only updates knowledge. Your files are untouched.
git pull         # fetch + merge: can change files and cause conflicts.

git fetch can never create a merge conflict or overwrite your work — it just refreshes what your machine knows. That makes it the safe first move when you’re unsure what’s going on. You can then look before you leap:

git fetch
git log HEAD..origin/main --oneline   # what's on GitHub that I don't have yet
git status                            # now this answer is actually current

The mental model

Think of origin/main as a photo of GitHub on your desk. git status reads that photo — fast, but as old as the photo. git fetch takes a fresh photo. git pull takes a fresh photo and rearranges your room to match it.

The lesson

• git status is only as current as your last fetch. “Up to date” means “up to date with what I last downloaded,” not “up to date with GitHub right now.”
• When in doubt, git fetch first, then read status/log. It costs nothing and changes nothing.
• Reach for git fetch + inspect before git pull when you want to see incoming changes before they touch your files.

One-line summary

git fetch updates your knowledge of GitHub without changing your files. git status is only as current as your last fetch — when in doubt, fetch first.