Understanding git pull: How it Combines git fetch and git merge, FETCH_HEAD, and Rebase Options

When you run git pull , it is equivalent to executing git fetch followed by git merge . The fetch step creates or updates the local FETCH_HEAD file, which records the remote branch names, latest commit IDs, and authors for the fetched references.

The FETCH_HEAD file is stored locally and does not change automatically; it is refreshed each time git fetch is run. You can inspect its contents with commands such as git log -p FETCH_HEAD or by opening the file directly.

git merge combines changes from two branches into a new merge commit, preserving full branch history, which is useful for collaborative projects but can make the history more complex. git rebase re‑applies a branch’s changes on top of another branch, producing a linear history that is easier to read, though it rewrites existing commits.

Typical merge workflow: fetch the latest changes, then merge the target branch (e.g., master ) into your feature branch ( test-* ). A concise two‑step process is often sufficient:

git fetch

git merge origin/master

This avoids unnecessary check‑outs and keeps the FETCH_HEAD file up‑to‑date, allowing you to merge without switching branches.

Since Git 1.7.10, the default strategy of git pull can be configured to use either merge or rebase. Use the following commands to set the global default:

git config --global pull.rebase true # use rebase

git config --global pull.rebase false # use merge

You can verify the setting with git config --global -l . Even when a default is set, you can override it per invocation with --rebase or --no-rebase .

In summary, git pull is a shortcut for fetch‑plus‑merge, but understanding the underlying steps, the role of FETCH_HEAD , and the merge vs. rebase trade‑offs gives you finer control over code integration.