Git fetch vs. pull: inspect changes before integrating them

git fetch retrieves objects and updates the references selected by the fetch configuration. git pull fetches first, then integrates the selected remote history into the current branch using the requested strategy.

With a normal clone configuration, git fetch origin updates references such as origin/main without changing your checked-out branch or working files. That gives you a chance to inspect incoming changes before deciding how to integrate them.

A fetch can still fail because of network, authentication, or reference-update problems. It also writes repository metadata; “does not merge files” does not mean “changes nothing.”

Fetch, inspect, then integrate

For a repository whose remote and branch are named origin and main:

git fetch origin
git log --oneline HEAD..origin/main
git diff --stat HEAD origin/main
git merge --ff-only origin/main

The log shows commits reachable from origin/main but absent from HEAD. The diff compares the two endpoint snapshots; if the branches have diverged, that is not simply a list of incoming changes. The final command advances your branch only when it can do so without creating a merge commit.

To see commits unique to either side before choosing a strategy:

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

Choose a pull strategy explicitly

git pull --ff-only origin main
git pull --rebase origin main
git pull --no-rebase origin main

Run one of these alternatives:

• --ff-only rejects divergent history instead of merging it.
• --rebase reapplies your local commits on the fetched history and changes their commit IDs. Coordinate before rewriting commits others already use.
• --no-rebase requests merge integration. A fast-forward is still possible; divergent histories may require a merge commit and conflict resolution.

Do not assume bare git pull always merges. Defaults depend on your Git version and configuration. The current pull manual documents fast-forward-only behavior as its default; explicit flags also make your intent clear on older installations.

For a repository-wide preference on your machine, choose a setting such as:

git config --local pull.ff only

Use --global only if you intentionally want the preference to apply across your repositories. Check existing pull.rebase and pull.ff settings before combining policies.

FAQ

What happens if I have uncommitted changes?

Merge-based integration can sometimes preserve non-overlapping changes, but Git rejects operations that would overwrite local work. Rebase normally requires a clean working tree unless autostash is enabled. An autostash can itself conflict when reapplied. Commit or stash the work first when you want a predictable starting point.

Can fetch move a local branch?

A normal git fetch origin updates remote-tracking branches. A custom refspec can target other local references, including a branch that is not checked out. Git normally refuses to fetch directly into the currently checked-out branch. The distinction comes from the configured destination references, not a universal rule that fetch only updates origin/*. See git-fetch.

Why split fetch and integration?

It gives you an inspection point. You can review commits, run a diff, and decide between fast-forward, merge, and rebase after you see how the histories relate. It does not eliminate conflicts or replace a clean working tree.