Push, Pull, and Fetch
These three commands are how a distributed Git repository stays synchronized with a remote. git fetch downloads new commits, branches, and tags from a remote into your local remote-tracking branches, without touching your working tree or local branches at all. git push uploads your local commits to update a branch on the remote. git pull is a convenience command that runs a fetch followed immediately by a merge (or, if configured, a rebase) of the fetched branch into your current branch. Of the three, fetch is the safest — it never changes your working files — while pull and push both modify state and can, in the wrong circumstances, cause conflicts or overwrite work.
Cricket analogy: Fetch is like watching the opposition's practice session through binoculars without stepping onto the field — you see what they're doing, but nothing changes on your own side until you decide to act on it, unlike actually walking out to bat (push) or adjusting your game plan mid-innings (pull).
Fetch: Look Before You Leap
git fetch updates your remote-tracking branches (e.g. origin/main) to match the remote's current state, but your local main branch is untouched until you explicitly merge or rebase. This makes fetch a safe way to see what has changed upstream — run git log main..origin/main or git diff main origin/main afterward to preview incoming changes before deciding how to integrate them. Experienced Git users often prefer explicit fetch + merge/rebase over pull precisely because it separates 'see what's new' from 'apply it', giving them a chance to review first.
Cricket analogy: This is like checking a live scoreboard from another ground without it affecting your own team's actual innings — you can compare it to your team's current total and decide how to respond, but nothing about your own game changes until you act on what you saw.
Pull, and Push's Failure Modes
By default git pull performs a merge, creating a merge commit if your local branch has diverged from the remote branch. Running git pull --rebase instead replays your local commits on top of the fetched branch, producing a linear history without a merge commit — many teams set pull.rebase = true globally so this becomes the default behavior. If your working tree has uncommitted changes that conflict with incoming commits, pull will refuse to proceed (or, in the rebase case, may pause partway through with a conflict) until you commit, stash, or discard those local changes. On the push side, git push uploads your local branch's commits to the corresponding remote branch and by default fails with a 'non-fast-forward' rejection if the remote branch has commits your local branch doesn't have — this is Git protecting you from silently discarding someone else's work. The correct fix is usually to git pull (or fetch + rebase/merge) first, resolve any conflicts, and then push again. git push --force overrides this protection and overwrites the remote branch unconditionally; git push --force-with-lease is the safer variant, which only forces if the remote hasn't changed since your last fetch, refusing otherwise.
Cricket analogy: This is like a captain refusing to declare an innings closed (push rejection) if the scoreboard shows the opposition has already added runs he hasn't accounted for — he must first check the latest total (pull) and reconcile before declaring, or use a verified override (force-with-lease) only if nothing changed since his last check.
# Safely inspect what's new upstream before merging
git fetch origin
git log --oneline main..origin/main
# Pull with rebase instead of merge, avoiding an extra merge commit
git pull --rebase origin main
# Push local commits on the current branch to origin
git push origin feature/checkout-redesign
# First push of a new branch: set it to track the remote branch
git push -u origin feature/checkout-redesign
# Rejected push (remote has commits you don't have)
# ! [rejected] main -> main (fetch first)
# hint: Updates were rejected because the remote contains work you don't have locally.
git pull --rebase origin main
git push origin mainAvoid git push --force on shared branches like main or develop — it silently overwrites the remote history, potentially deleting commits your teammates already pushed. If a force push is genuinely necessary (e.g. after an interactive rebase on your own feature branch), use git push --force-with-lease and communicate the change to anyone else working on that branch.
A useful mental model: fetch is 'download mail and put it in my inbox', pull is 'download mail AND automatically file it into my folders (merge/rebase)', and push is 'mail my outgoing letters'. Fetch alone never rearranges anything you already have.
git fetchdownloads remote changes into remote-tracking branches without touching your working branches.git pull= fetch + merge (or rebase, with--rebaseorpull.rebase = true) into the current branch.git pushuploads local commits to update a remote branch, and is rejected if it isn't a fast-forward.-u/--set-upstreamon the first push links a local branch to its remote counterpart for future plainpush/pull.--force-with-leaseis a safer alternative to--force, refusing to overwrite unseen remote commits.- Preferring explicit fetch + review + merge/rebase over blind pull gives you a chance to inspect incoming changes first.
Practice what you learned
1. What is the key difference between `git fetch` and `git pull`?
2. Why does `git push` get rejected with a 'non-fast-forward' error?
3. What does `git push -u origin feature-x` do beyond pushing the branch?
4. How does `git push --force-with-lease` differ from `git push --force`?
5. What does `git fetch` alone do to your currently checked-out branch's files?
Was this page helpful?
You May Also Like
Remotes Explained
A remote is a named reference to another copy of a repository, usually hosted elsewhere, that Git uses to synchronize commits, branches, and tags between machines.
Tracking Branches
A tracking branch is a local branch configured with a direct relationship to a remote branch, enabling short commands like plain `git push` or `git pull` and clear ahead/behind status.
Rebasing vs Merging
Compare git rebase and git merge as two different strategies for integrating branch changes, and learn when a linear history is worth the trade-offs of rewriting commits.
Git Flow and Trunk-Based Development
Two contrasting branching strategies for organizing a team's work — Git Flow's structured long-lived branches versus trunk-based development's short-lived branches off a single trunk.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics