Remote Workflow

fetch vs pull, tracking branches, and keeping your local repo in sync without surprises

Why

The fetch-vs-pull distinction is one of the most common sources of "why did my code get overwritten?" moments on teams. Understanding that git fetch only downloads — and never touches your working directory — gives you safe, predictable control over how and when local branches integrate remote changes.

Intuition

Remote-tracking branches like origin/main are local read-only snapshots of what the remote looked like last time you communicated. git fetch updates these snapshots without touching anything else. git pull = fetch + merge (or rebase). Think of origin/main as a cached copy, not a live view — you must fetch to refresh it.

Explanation

fetch, pull, push

git fetch origin # download remote changes, update origin/* refs # does NOT touch working directory or local branches git pull # = git fetch + git merge origin/<current-branch> git pull --rebase # = git fetch + git rebase onto origin/<current-branch> # avoids a merge commit; keeps history linear git push origin feature/login # publish local branch to remote git push -u origin feature # -u sets upstream tracking; future git push just works

Safe sync pattern

git fetch origin git log HEAD..origin/main # inspect what's new remotely before integrating git merge origin/main # merge when you're ready # See tracking relationships git branch -vv # Remove a remote branch git push origin --delete feature/old-branch

Fetching before inspecting gives you full visibility into incoming changes before they touch your branch. It is always safe — nothing changes locally until you explicitly merge or rebase.

← Previous Next →