Fetch Without Merge
Asha comes back from a week away. Ravi and a cousin have been busy. She wants to see what they did before any of it touches her working files. git pull would merge straight away; git fetch lets her look first.
The rule
Fetch downloads and updates
origin/*; your branches and files stay untouched.
git fetch # from origin, by default
git fetch --all # from every remoteFetching downloads new commits and moves the remote-tracking branches, such as origin/main, to match the server. It does not change your local main, your staging area or a single file in your working directory. That makes it completely safe to run at any time.
After fetching, git status can tell you how far apart you are:
git status
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.Now inspect before you combine:
git log --oneline main..origin/main # commits on origin/main that main lacks
git diff main origin/main # how origin/main's files differ from main'sRead main..origin/main as "what origin/main has that main does not".
When you are happy, merge the remote-tracking branch into yours:
git merge origin/maingit fetch followed by git merge origin/main is exactly what git pull does in one step. Splitting it gives you a moment to look, which matters most when you have been away, when the team is large, or when you have local commits of your own that could conflict.
Fetching also tells you about new branches others pushed. They appear as origin/<name>. To work on one, run git switch <name>; if a remote branch with that name exists, Git creates a matching local branch that tracks it.
Fetch also has a housekeeping option. When teammates delete branches on the remote, your old origin/<name> records linger. git fetch --prune removes remote-tracking branches whose remote branch no longer exists, so git branch -r shows only what is really there.
The shortcut
Think of origin/main as a mailbox. fetch puts new mail in it. log main..origin/main and diff read the mail. merge origin/main brings it inside. pull does all three without letting you read first.
Collect the mail
git fetch. Hermainand files are unchanged;origin/mainjumps ahead.
The trap is expecting git fetch to change your files, then thinking it "did nothing". It did its job: look at origin/main, not main.
Drills
Answer fast — trust the rule.
After git fetch, which of these has changed?
Which pair of commands does the same as git pull on main?
What does git log --oneline main..origin/main list?
Why might Asha choose git fetch over git pull after a week away?
Ravi pushed a new branch rasam-variations. After git fetch, how does Asha start working on it?
Remember
- Fetch downloads and updates
origin/*; your branches and files stay untouched. - Mailbox: fetch collects,
log main..origin/mainanddiffread,merge origin/mainbrings it in. - Pull equals fetch plus merge, with no chance to look first.
