In Git, what is FETCH_HEAD and when would you use it directly?

## What the file is `FETCH_HEAD` is not a branch and not a normal ref — it is a plain text file at `.git/FETCH_HEAD` that `git fetch` rewrites on every run. Each line records one ref that the fetch brought down: the object ID, an optional `not-for-merge` marker, and a human-readable description of where it came from, for example the branch name and the remote URL. The first line without the `not-for-merge` marker is the one Git treats as "the thing you fetched in order to integrate", and the name `FETCH_HEAD` resolves to that object ID anywhere Git accepts a revision. ## Why it exists at all Remote-tracking refs only exist for refs covered by a configured refspec — by default `+refs/heads/*:refs/remotes/origin/*` for a named remote. Plenty of fetches fall outside that. You can fetch straight from a URL with no remote configured; you can fetch a single ref that has no local counterpart. In those cases Git still has to tell you where the downloaded work is, and `FETCH_HEAD` is the answer. It is the universal landing spot for "whatever the last fetch produced". This also explains the classic definition of `git pull` as fetch plus merge: the second half is conceptually `git merge FETCH_HEAD`. Understanding that removes most of the mystery from pull's behaviour — when a merging pull creates a merge commit, the second parent is the commit that `FETCH_HEAD` named. ## Using it After a fetch, `FETCH_HEAD` behaves like any revision. `git log FETCH_HEAD` shows the fetched history. `git log HEAD..FETCH_HEAD` shows what arrived that you do not have. `git diff HEAD...FETCH_HEAD` shows the net change. `git merge FETCH_HEAD` integrates it, and `git cherry-pick FETCH_HEAD` takes just the tip commit. A typical use is reviewing a contribution from a repository you do not want to add as a permanent remote: fetch its URL and branch, inspect `FETCH_HEAD`, then merge or discard it — no remote, no branch, nothing to clean up afterwards. ## Lifetime and gotchas The file is overwritten by the next fetch, so treat it as a scratch pad, not storage. `git fetch --append` adds to it instead of replacing it, which is how a multi-remote fetch accumulates entries. `git fetch --dry-run` never writes it. If you fetched something you want to keep, create a real ref: `git branch review FETCH_HEAD` or `git tag`. Otherwise the object is unreferenced once `FETCH_HEAD` is overwritten and becomes eligible for garbage collection. A second subtlety is that a normal `git fetch origin` writes both remote-tracking refs **and** `FETCH_HEAD`. People often assume the two are alternatives; they are not. Remote-tracking refs are the durable, per-branch record you compare against every day; `FETCH_HEAD` is the transient record of the last fetch operation itself. ## Where it shows up in real work Beyond ad-hoc review, `FETCH_HEAD` is what makes `git pull <url> <branch>` work at all — there is no remote-tracking ref in that form, so pull merges `FETCH_HEAD`. Scripts sometimes fetch a ref and act on `FETCH_HEAD` rather than inventing a temporary branch name. And when you are debugging a confusing pull, reading `.git/FETCH_HEAD` tells you precisely which object the integration step was handed, which is often faster than reasoning about refspecs. ## Interview framing The question is really a probe for whether you understand fetch as an operation with its own output, distinct from the remote-tracking refs it usually also updates. A candidate who can say "pull is fetch then merge FETCH_HEAD" and can name a case where no remote-tracking ref exists has demonstrated exactly that.