What is the difference between git fetch and git pull?

## The two halves of "getting other people's work" Getting changes from a remote is really two independent steps: **transfer** and **integration**. `git fetch` does only the transfer. `git pull` does the transfer and then immediately does the integration for you. Almost every confusing thing about `git pull` follows from the fact that its second half is a separate command running on your behalf. ## What git fetch actually changes When you run `git fetch origin`, Git connects to the remote, negotiates which objects you are missing, and downloads them into your object database. It then updates your **remote-tracking refs** — local, read-only bookmarks that record where the remote's branches were at the moment you last fetched. They live under `refs/remotes/origin/` and you name them `origin/main`, `origin/feature-x`, and so on. Which refs get updated is decided by the remote's fetch refspec, by default `+refs/heads/*:refs/remotes/origin/*`. What fetch does **not** touch: your current branch (`refs/heads/...`), `HEAD`, the index, and the files in your working tree. Because of that, a fetch can never produce a merge conflict, can never fail because you have uncommitted edits, and can never lose local work. It is safe to run at any time, including in the middle of your own messy work. The only thing that grows is your object database. After fetching, nothing about your checkout has changed — but `origin/main` now points at the real remote tip, so you can inspect the incoming work: `git log --oneline HEAD..origin/main` lists commits they have that you do not, and `git diff HEAD...origin/main` shows what those commits change. ## What git pull adds `git pull` runs `git fetch` with the same arguments and then, depending on configuration, runs either `git merge` or `git rebase` to reconcile your branch with the fetched tip. Three outcomes are possible: - **Fast-forward.** If you have no local commits of your own, your branch pointer simply slides forward to the fetched commit and the working tree is updated. This is what most people picture when they say "pull". - **Merge or rebase.** If you and the remote have both added commits, the histories have diverged. A merging pull creates a merge commit joining the two lines; a rebasing pull replays your local commits on top of the fetched tip, producing new commits with new hashes. - **Conflict or refusal.** The integration step can stop mid-way with conflict markers in your files, or refuse to start at all — a rebasing pull will not run with a dirty working tree, and modern Git aborts a diverging pull entirely if you have not told it whether to merge or rebase. Because pull mutates your branch and your files, it is the command that can leave you in a half-finished state. Fetch never can. ## Why interviewers care The distinction explains a whole family of everyday problems: the surprise merge commits that appear in a shared branch's history, the "why did pull just try to rewrite my commits" confusion, and conflicts arriving at an inconvenient moment. It also explains the standard safe workflow: fetch first, look at what arrived with `git log` or `git diff`, then choose the integration deliberately — `git merge --ff-only origin/main` when you just want to catch up, an explicit merge or rebase when you have diverged. ## Practical notes `git fetch --all` updates every configured remote. `git fetch` with no arguments fetches the remote configured for the current branch, falling back to `origin`. If you never fetch, your `origin/main` is stale — it reflects the last fetch, not the remote's current state, which is why `git status` can cheerfully report "up to date" while the remote is fifty commits ahead. Teams that dislike accidental merge commits usually configure the integration half explicitly rather than banning `git pull` outright.