What does git fetch do? (and how it differs from git pull)
Two commands trip up nearly everyone new to Git: fetch and pull. They sound like the same thing, and half the tutorials use them as if they are. They are not. Once you see the one line that separates them, you will reach for the right one on purpose instead of by habit.
New to cloud? CAMPUX is a free, build-first course. Start here →
git fetch downloads new commits, branches, and tags from a remote into your local remote-tracking branches (like origin/main) without changing your working files or current branch. git pull does the same fetch and then immediately merges (or rebases) those changes into your branch. Fetch is the safe look-first step. That is the whole distinction, and everything below is just filling in why it matters and how to use each one well.
The short answer
When you run git fetch, Git contacts the remote — usually the one called origin — asks what has changed since you last synced, and downloads any commits, branches, and tags you are missing. It writes all of that into your local repository. What it does not do is touch the branch you have checked out or a single file in your working directory. Your work sits exactly where you left it. Fetch is Git quietly catching your local copy up on what other people have pushed, and then waiting for you to decide what to do about it.
Pull skips the waiting. It fetches, and then it integrates those changes into your current branch right away. That second step is the entire reason the two commands feel different in practice: pull changes your files, fetch does not.
What "remote-tracking branch" means (origin/main)
To understand fetch you have to understand where the downloaded commits actually land. When you clone a repository, Git sets up two kinds of branches. There is your local main, the one you check out and commit to. And there is origin/main, a remote-tracking branch — Git's private, read-only bookmark for "where main was on the remote the last time I checked."
You do not commit to origin/main. You cannot, really; it moves only when Git talks to the remote. Think of it as a snapshot of the server's state that lives on your machine. The moment someone else pushes to the remote, your origin/main becomes stale — it still points at the old commit — until you fetch. Fetching is precisely the act of updating that bookmark:
git fetch origin
After that command, origin/main points at whatever is now on the server, while your local main stays put. The gap between the two is the set of commits you have not integrated yet. Being able to see that gap without disturbing your work is the whole point of fetch.
git fetch, step by step
Here is what actually happens when you fetch, and how you inspect the result. Start with the fetch itself:
git fetch origin
Now your remote-tracking branches are current. To see what came down — the commits that are on origin/main but not yet on your branch — ask Git for the range between the two:
git log HEAD..origin/main
Read the two dots as "everything in the second that is not in the first." HEAD is where you are; origin/main is where the server is. So this lists exactly the incoming commits, newest work that your teammates pushed while you were heads-down. You can read the messages, see who wrote what, and get a feel for whether integrating is going to be quiet or interesting. If the command prints nothing, you are already up to date and there is nothing to merge.
When you have looked and you are ready to bring those commits into your branch, you merge the remote-tracking branch into your local one:
git merge origin/main
Only at this step do your files move. Merge takes the commits Git already downloaded during the fetch and weaves them into your branch, creating a merge commit if the histories diverged. There is no second trip to the network — fetch already pulled the data down, so merge is a purely local operation.
Fetch brings the changes to your machine. Merge brings them to your branch. Pull does both in one breath.
git fetch vs git pull — the real difference
Now the comparison, side by side. The short version: git pull is defined as git fetch followed by git merge. Run it and you get both steps with no chance to look in between.
| git fetch | git pull | |
|---|---|---|
| What it downloads | New commits, branches, and tags from the remote | The same — it runs a fetch first |
| What it changes | Only remote-tracking branches like origin/main | Remote-tracking branches and your current branch and files |
| Touches your working files? | No | Yes — it merges or rebases into your checkout |
| Can cause a merge conflict? | No | Yes, at the integration step |
| Safety | Always safe — nothing you are editing can be overwritten | Fine on your own branch; can surprise you on a shared one |
So the plain form is a single command that does the lot:
git pull
That is a fetch plus a merge, aimed at whatever branch you have checked out. Nothing wrong with it — it is convenient and it is what you want most of the time on a branch only you touch. The trouble is that it merges before you have seen what is coming, and if the merge hits a conflict, you find out mid-command rather than on your own terms.
The safe workflow most teams use
On a branch several people push to, a lot of engineers deliberately split pull back into its two halves. The pattern is fetch, inspect, then merge:
git fetch origin git log HEAD..origin/main git merge origin/main
Fetch is free and safe, so you run it often just to stay aware. The git log line tells you what you are about to take on — three tidy commits, or a big refactor that is going to touch the same files you have open. Armed with that, you decide when to merge. If it is a bad moment, you finish your thought, commit, and merge on your schedule. You never get ambushed by an integration you did not ask for.
Fetch costs nothing and changes nothing, so make it reflexive — run git fetch before you start work and before you push. Seeing origin/main move early is far kinder than discovering, at push time, that the remote grew ten commits while you were not looking. The person who fetches often is rarely the person untangling a surprise conflict at 6pm.
When to use pull --rebase
There is a third path worth knowing, because it changes the shape of your history. A plain pull merges, which can leave a trail of small merge commits every time you sync. If you would rather keep history flat, tell pull to rebase instead:
git pull --rebase
That fetches, then replays your local commits on top of the fetched ones, as if you had written your work after everyone else's. No merge commit, a straight line of history. It reads cleanly, and many teams prefer it for feature branches. The tradeoff is that rebase rewrites your local commits, so it is a poor fit once you have pushed and others may have based work on those commits. The safe rule: rebase your own un-pushed work, merge when history is shared. If you want the split-out version of the same idea, git fetch followed by git rebase origin/main gives you the look-first pause before the replay.
Questions people also ask
Is git fetch safe?
Yes. git fetch only updates your remote-tracking branches, such as origin/main, and downloads any new objects into your local repository. It does not touch your working files, your staged changes, or the branch you have checked out. Nothing you are editing can be overwritten by a fetch, which is why it is the safe way to see what has changed on the remote before you decide to merge.
What is the difference between git fetch and git pull?
git fetch downloads new commits from the remote and updates your remote-tracking branches, but stops there and leaves your current branch alone. git pull runs that same fetch and then immediately merges, or rebases, the fetched changes into your checked-out branch. So pull is fetch plus an automatic integration step, while fetch just brings the data in and waits for you to decide what to do with it.
Does git fetch change my working files?
No. git fetch never changes the files in your working directory and never moves the branch you have checked out. It only advances the remote-tracking branches like origin/main and stores the new commits in your repository. Your files change only when you follow up with a merge or rebase, or when you run git pull, which does that integration step for you.
Should I use git pull or git fetch?
Use git fetch when you want to look before you act: fetch, inspect the incoming commits with git log HEAD..origin/main, then merge when you are ready. Use git pull when you trust the incoming changes and want the fetch and merge in one step, for example on a branch only you work on. Many teams default to fetch-then-merge on shared branches to avoid surprise merges.