Undo a Git pull and recover the previous state

Identify whether pull merged, rebased, or fast-forwarded, preserve current work, and choose the verified pre-pull commit before resetting.

Best practices
Illustration of Git branches and version history

If the pull is still in a merge or rebase, use that operation's abort command after preserving anything important. If it completed, inspect the reflog to find the pre-pull commit. Do not run reset --hard ORIG_HEAD without checking what ORIG_HEAD currently means.

Identify the operation and target

git status
git reflog --date=iso
git show --no-patch --oneline ORIG_HEAD

A pull fetches and then integrates changes. Integration may fast-forward, merge, or rebase, depending on options and configuration. ORIG_HEAD may record the prior tip, but later operations can replace it; an unsuccessful or no-op pull does not make it a reliable marker for that attempt.

Use commit messages, dates, and diffs to verify the intended pre-pull commit. The reflog is local, and its entries are not guaranteed to remain indefinitely.

Abort an operation still in progress

State reported by Git Relevant command
Merge in progress git merge --abort
Rebase in progress git rebase --abort
Integration already completed Inspect history and choose a recovery operation

A merge abort cannot always reconstruct pre-existing uncommitted changes perfectly. Save needed files outside the repository when conflicts prevent stashing. Do not start another reset merely to make the conflict messages disappear.

Reset a completed pull locally

Create an unused rescue branch for the current commits, and separately save uncommitted files:

git branch rescue-before-undo-pull
# When there are no unmerged entries, stash can help preserve local changes:
git stash push -u -m "Local work before undoing pull"
# Only after verifying the target and saving needed files:
git reset --hard PRE_PULL_COMMIT

Substitute the verified commit ID. A rescue branch does not save working-tree contents. --hard replaces the index and tracked working files and can remove untracked paths that obstruct the target tree. stash -u omits ignored files; preserve those separately when needed.

The same principle applies after a fast-forward, a completed merge, or a completed rebase. For rebase, inspect the original branch history carefully rather than selecting an arbitrary intermediate reflog entry.

Recover again or choose another integration strategy

If you change your mind, the rescue branch identifies the post-pull commit. Review it and save current work before restoring that state. Without a rescue ref, reflog recovery depends on the objects still being present.

A local reset does not remove commits from the remote or change another clone. A later pull may integrate the remote changes again. If the unwanted integration was already published as shared history, consider a new corrective or revert commit instead of assuming a force push is appropriate. Reverting a merge requires choosing its mainline parent and affects later merge behavior.

To retry integration differently, fetch and inspect the current remote-tracking branch, then choose merge or rebase according to the team's workflow. Reapply saved local work deliberately; stash application can conflict and should be reviewed before dropping the entry.

See git-pull, git-reset, and git-reflog.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting