Look before you merge
git pull is convenient but blunt. Whatever the remote has gets merged into your branch immediately, possibly rewriting files mid-thought or dropping a conflict in your lap at the worst possible moment.
When you would rather see what the team changed before it lands in your files, use the cautious half of pull.
$ git fetch remote: Counting objects: 5, done. c7d8e9f..f0e9d8c main -> origin/main
It downloads the remote's new commits and stops there. Your files and your branches do not move. The news lands on a read-only pointer named origin/main, a remote-tracking branch, which means where main was on the server the last time you checked.
With the commits downloaded but not merged, the tools from lessons 3-1 and 3-2 become inspection tools.
$ git log --oneline main..origin/main $ git diff main origin/main $ git merge origin/main
The first lists the commits they have that you do not, the second shows the exact line changes, and the third brings them in once you are satisfied.
Fetch, inspect, merge is exactly what git pull does, with a thinking step inserted in the middle. Use pull when you trust the update and want it now, and fetch when you would rather peek first.
A recorded session
This session walks a careful sync. A teammate pushed to origin overnight, and the changes get inspected before they touch local files.
Each step below shows the command and the output it printed.
Step 1. Download the remote's news without changing any of your branches or files.
~/recipe-book $ git fetch remote: Counting objects: 5, done. From https://github.com/octocat/recipe-book c7d8e9f..f0e9d8c main -> origin/main
The arrow points at origin/main, not main, which is the whole distinction: the remote-tracking pointer moved and your branch did not.
Step 2. List the commits they have that you do not.
~/recipe-book $ git log --oneline main..origin/main f0e9d8c Fix cake baking time
Step 3. One harmless fix, so bring it in.
~/recipe-book $ git merge origin/main
Updating c7d8e9f..f0e9d8c
Fast-forward
cake.txt | 2 +-A fast-forward, since you had made no commits of your own. Had the review turned up something you were not ready for, stopping after step 2 and merging later would have been a perfectly valid outcome.
No, git fetch can never change the files in your working directory or create a merge conflict.
It only downloads commits and updates origin/main. Your files and your own branches stay exactly as they were, which makes fetch safe to run at any moment, including in the middle of unfinished work.
Conflicts can only appear at the merge step, whether you run that merge yourself or let pull run it for you. Separating the download from the merge is therefore a way of choosing when you are willing to deal with a conflict, rather than a way of avoiding one.
The name origin/main refers to your local record of where the main branch was on the origin remote at your last fetch.
It is a remote-tracking branch, meaning a local read-only bookmark of the server's position, refreshed every time you fetch or pull. It is not live, so it can be out of date, and it never updates on its own.
Its practical use is comparison. Since both main and origin/main are ordinary commit pointers, git log main..origin/main and git diff main origin/main tell you exactly how far ahead or behind you are and what the difference consists of.
The command that downloads the remote's new commits without merging is git fetch.
It updates origin/main and touches none of your work, so it is the half of pull that carries no risk.
The natural follow-up is inspection with git log or git diff against origin/main, then git merge origin/main once you are ready to accept the changes. Splitting the operation that way costs one extra command and buys you control over the timing of every merge.