Git Fetch vs Pull: Inspect Remote Changes Before Updating Your Branch

git fetch brings remote information into your repository without merging it into your current branch. git pull fetches and then tries to integrate a branch, using a merge or rebase according to your options and configuration. If you want to see what changed before deciding how to integrate it, fetch first and compare the two histories.

This guide uses a local branch named main and a remote called origin, with main tracking origin/main. Substitute your own names. It assumes a normal clone with a configured remote and an existing upstream; check those assumptions before running the example. The behaviour described here follows the Git 2.49 pull manual, released in March 2025.

Check the branch and protect unfinished work

In the repository, run:

git status --short --branch
git branch -vv
git remote -v

The first command identifies the checked-out branch and local changes. The second shows local branches and their configured upstreams; the third lists remote names and URLs. If your current branch has no upstream or tracks something other than origin/main, do not copy the comparison below blindly. Ask your project which branch you should compare. If you are in a detached HEAD state, stop and identify the intended branch first.

Fetching normally leaves your checked-out files and local branch alone, but later integration can change them. Commit work you intend to keep, or use a named stash for an interruption after checking what it includes. Start a merge with a clean working tree when possible: Git warns that aborting a merge may not reconstruct pre-existing uncommitted changes.

Fetch, then inspect the incoming commits

git fetch origin
git status --short --branch
git log --oneline HEAD..origin/main

Fetch downloads the objects and refs needed from origin and updates applicable remote-tracking references. origin/main is your local record of the remote branch as last fetched; it is not a live connection to the server. Another person can push after your fetch, so fetch again when freshness matters. Fetch can fail because of authentication, connectivity or remote configuration; if it fails, fix that first rather than assuming the comparison is current. See the versioned fetch manual.

In HEAD..origin/main, Git lists commits reachable from origin/main but not from your current commit. An empty list means there are no commits exclusive to the fetched side under that comparison; it does not prove the working tree is clean or that the server has not changed since the fetch. To see the content of a particular incoming commit, replace the example ID with one from your output:

git show --stat abc1234
git show abc1234

Commit messages and diffs are evidence to review, not a guarantee that a change is safe for your project.

See whether the histories have diverged

For a two-sided view, run:

git log --left-right --oneline HEAD...origin/main

A line marked < is reachable only from the left side, HEAD; > marks a commit only on the right, origin/main. The three dots here are a symmetric difference of commit histories, as described in the Git log manual. For example:

< a1b2c3d Local documentation change
> d4e5f6a Remote bug fix

This illustrative output shows one commit exclusive to each side: the branches have diverged. If only > lines appear, your current commit is an ancestor of the fetched tip in this ordinary comparison, so a fast-forward may be possible. If only < lines appear, the fetched tip is an ancestor of your current commit. No lines means both references point to the same commit. Commit IDs are examples; your output will differ.

These are ancestry comparisons, not a semantic comparison of the changes. A cherry-picked commit can contain an equivalent patch with a different ID and still appear on both sides. Also, do not transfer the meaning of three dots in git log to every Git command: git diff A...B uses a merge-base comparison with B, not the same commit-list operation.

Choose an integration deliberately

If your team's policy allows a fast-forward and you have confirmed the target is correct, this command updates the current branch only when a fast-forward is possible:

git merge --ff-only origin/main

If the branches have diverged, it stops instead of creating a merge commit. That refusal is useful information: review the two sides and follow your project's merge or rebase policy. Do not reset the branch just to make it match the remote; local commits may be work you need.

A merge can produce conflicts when both sides change the same area. If that happens, git status shows the affected paths. Read both changes, resolve and stage the intended result, then continue the merge; the merge conflict walkthrough covers that process. If a rebase is in progress, use its own continuation or abort commands instead of the merge commands. Git's merge documentation explains fast-forwards, conflicts and the limits of aborting with local changes present.

After integration, run git status --short --branch and the tests appropriate to the changes. A successful Git operation establishes that Git completed its operation; it does not establish that the combined software works.

When is pull useful?

Use git pull when you already know which upstream and integration policy you want and are ready for both steps together. Its exact behaviour depends on options and configuration; it is not always equivalent to a merge. Use separate fetch and review steps when you need to inspect what is coming or check whether your branch has diverged. Neither workflow prevents another push immediately afterward, so coordinate with your team when the exact remote tip matters.

Sources

• Git 2.49.0: fetch — remote refs and fetch behaviour.
• Git 2.49.0: pull — fetch followed by integration and upstream configuration.
• Git 2.49.0: log and revision selection — commit ranges and left/right markers.
• Git 2.49.0: merge — fast-forward-only and merge recovery.