git pull is the command everyone learns first and understands last. It is not one operation - it is git fetch followed immediately by git merge (or git rebase, depending on your config). Splitting them apart is worth the ten seconds it takes, because the second half is where surprises live.
Fetch: look before you leap#
git fetch origin
Fetch downloads new commits from the remote and updates your remote-tracking branches - origin/main and friends - without touching your working tree or your local branches at all. Nothing can conflict, nothing can be overwritten. It is pure information.
That makes fetch the safe first step:
git fetch origin
git log --oneline HEAD..origin/main
The log shows exactly what arrived while you were working. If the answer is three commits you already know about, merging is a formality. If it is a force-push or a rewritten history, you found out before it landed in your branch - which is also why teams that force-push feature branches should force-push with lease.
Merge or rebase: the second half#
Once fetched, you choose how to combine:
git merge origin/main- creates a merge commit when both sides moved. Honest history, extra bubbles.git rebase origin/main- replays your unpushed commits on top, keeping history linear. Cleaner, but it rewrites your local commits, so only for work nobody else has.
git pull picks one of these for you based on config (pull.rebase, or merge by default). Teams that care should pick deliberately - Merging vs Rebasing for Small Teams is the full argument, and a one-line git config pull.rebase true (or pull.ff only) makes the default explicit instead of accidental.
A small daily upgrade#
Replacing the reflexive git pull with fetch, look, then merge-or-rebase costs seconds and buys two things: no surprise merge commits in the middle of your work, and no discovering a conflict after you have mentally committed to it. When conflicts do show up, Resolving Merge Conflicts Without Panic has the rest of the drill.
The one-line summary: fetch is reading, pull is reading plus writing. Read first.
Share this post
Keep reading
Annotating Commits with git notes: Metadata Without Rewriting History
Some things belong on a commit but not in it: review links, benchmark results, the ticket nobody remembered to reference. git notes adds them after the fact, no rebase required.
Backing Up Your Git Server So It Actually Restores
Every clone is a partial backup - but hooks, config and server state live outside the repo. Mirror, bundle, copy off-site, and rehearse the restore.
Cherry-Picking: One Commit Without the Branch
Cherry-pick copies a single commit onto your branch and leaves the rest behind. Right for hotfixes across release branches, wrong as a sync strategy.