Undo a completed Git rebase

To undo a completed rebase, find the branch tip from before the rebase and move the branch back to that commit. A reflog is often the easiest way to find it, but a backup branch or another retained ref can work too.

Preserve the current state

git status
git branch backup-after-rebase
git reflog show --date=iso HEAD
git reflog show --date=iso feature-x

Use your actual branch name and an unused backup name. The backup preserves the rebased commits, not uncommitted edits; save those separately before resetting.

Reflogs usually display newest entries first. The rebase (start) entry records the commit checked out to begin the operation, not necessarily your old feature-branch tip. Inspect the older entry preceding the operation and the branch's own reflog, then verify the candidate:

git show --stat PRE_REBASE_COMMIT
git log --oneline PRE_REBASE_COMMIT

Replace the placeholder with a real verified ID. Do not rely on a fixed HEAD@{N} offset copied from someone else's example.

Restore the old branch tip

After saving current edits and confirming the correct branch is checked out:

git branch recovered-before-rebase PRE_REBASE_COMMIT
git reset --hard PRE_REBASE_COMMIT

The recovery branch protects the old commits while you verify the result. A hard reset discards current tracked edits and can remove untracked paths that obstruct restoring tracked files. git stash push -u can save ordinary untracked files with tracked changes, but ignored files and submodule work need separate consideration.

If the rebase is still running

git rebase --abort

This returns the operation to its starting state rather than completing the rewrite. Save any conflict-resolution work you want separately before aborting. --quit is different: it stops rebase bookkeeping without restoring the original branch state in the same way.

If the rewritten branch was pushed

Resetting locally does not change the server. Replacing the published tip again requires a coordinated non-fast-forward update, usually with a scoped explicit lease after reviewing the remote. Other developers may have built on the rewritten commits, so preserve their work before choosing a recovery plan. Keeping the published history and adding corrective commits may be preferable.

FAQ

How long is recovery available?

Reflog expiration and object pruning are separate, configurable mechanisms. Create a recovery ref promptly; no fixed retention window guarantees recovery.

Is ORIG_HEAD enough?

Rebase sets it at the start, but other operations can overwrite it, including operations performed during the rebase. Inspect it as a clue, not as unquestioned proof of the desired commit.

Can I undo just a squash or reorder?

There is no universal single-step undo for a completed rewrite. Recover the original commits on a branch, then replay or rebase the desired sequence. Compare the resulting files as well as the commit graph.

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