Recovery

Undo after a pull you regret

When a pull leaves your branch in an unexpected state, first determine what pull actually did, then recover with ORIG_HEAD, reflog, or a rescue branch.

Who This Is For
  • Anyone actively handling a Git mistake
  • Readers who want a conservative rescue habit before trouble happens
Prerequisites
  • Stop mutating the repo further
  • Be ready to inspect `git reflog`, `git status`, and `git log --graph`
Common Risks
  • Running more reset or rebase commands before preserving a checkpoint
  • Changing shared history before assessing blast radius

Do not start with “how do I undo pull?”

Start with: what did git pull actually do?

It may have:

  • only fetched and fast-forwarded
  • created a merge commit
  • or rebased your local commits, depending on configuration

Those are different recovery situations.

First classify the pull resultDo not treat every bad pull as one kind of problem. First determine whether the pull fast-forwarded, merged, or rebased.
Inspect first
git statusgit log --oneline --graphgit reflog
Possible outcomes
fast-forwardmerge commitrebased history
Recovery is safer once you know whether pull changed only the pointer, created a merge node, or rewrote commit identities.

First round of checks

git status
git log --oneline --graph --decorate -n 20
git reflog

Typical clues:

  • a new merge commit means merge-based pull
  • a rewritten-looking sequence means rebase-based pull
  • a simple pointer move usually means fast-forward

Why ORIG_HEAD matters

Many merge and pull flows leave the previous position in ORIG_HEAD:

git show ORIG_HEAD
git switch -c rescue/before-pull ORIG_HEAD

That is often the cheapest first safety step.

Three common rollback paths

1. The pull only fast-forwarded

If you simply want the old position back:

git reset --hard ORIG_HEAD

But create a rescue branch first if the state still matters.

2. The pull created a merge commit

If that merge has not been shared, moving back may be reasonable.
If it has already become part of team history, treat the problem more like a shared-history correction and consider revert instead.

3. The pull used rebase

Then this is closer to “recover after a bad rebase.”
Use reflog, recover the pre-pull position, and preserve it with a rescue branch first.

A safer long-term habit

Many bad-pull stories happen because pull combines “observe remote updates” and “mutate my current branch” in one step.
The more conservative routine is:

  1. git fetch
  2. inspect the graph and status
  3. explicitly choose merge, rebase, or wait

Recommended order

  1. Identify what kind of pull this was
  2. Inspect ORIG_HEAD and reflog
  3. Create a rescue/* branch
  4. Then choose reset, revert, or a cleaner resync

A useful rule

If you do not yet know whether the pull merged or rebased, do not rush into reset.
Preserve the pre-pull position first.