How to Undo a Git Rebase

If a rebase is still running or stopped on a conflict, git rebase --abort returns to the pre-rebase state. If the rebase already finished, use the reflog to find the original branch tip, inspect it, and restore it carefully. The key is to distinguish an unfinished rebase from a completed one before changing history.

Check whether the rebase is in progress

Start by checking Git's status and recent history:

git status
git log --oneline --decorate -5

If Git reports a rebase in progress, abort it with the command below. If the rebase completed and the new commits are in the log, find the original tip in the reflog instead. Before restoring anything, save or commit any unrelated uncommitted work.

Abort a rebase that has not finished

If the rebase stopped because of conflicts, or you simply want to cancel it, run:

git rebase --abort

Git attempts to restore the branch to its state before the rebase began. Afterward, run git status and check the branch history. If you only want to stop the rebase but leave the current index and working tree as they are, git rebase --quit has different behavior; it is not the usual command for undoing a rebase.

Find the pre-rebase commit in the reflog

A completed rebase creates new commit IDs for the replayed commits. Git's local reflog records recent movements of HEAD and branch references, which can help locate the previous tip:

git reflog --date=local

Look for the entry from before the rebase began—often labeled with a rebase action—or inspect the branch reflog with git reflog show branch-name. Do not assume a particular shorthand such as HEAD@{1} is always the right commit: the number of reflog entries depends on the operations Git recorded.

ORIG_HEAD may also point to the old tip, but another Git command can overwrite it. Treat it as a lead to verify, not as a guaranteed recovery point. For more detail, see how to recover commits with the Git reflog.

Inspect and preserve the original tip

Replace <commit-id> with a candidate from the reflog and inspect it before moving the branch:

git show --stat <commit-id>
git log --oneline --decorate <commit-id>

Confirm the commit contains the work you expect. To keep it reachable without changing your current branch, create a rescue branch:

git branch rescue-pre-rebase <commit-id>

A rescue branch gives you a safe reference while you decide how to proceed. You can compare the old and rebased histories before replacing the current branch tip.

Restore the branch after a completed rebase

If you want the current branch to point exactly to the verified pre-rebase commit, first make sure your working tree has no valuable uncommitted changes. Then reset to the inspected commit ID:

git reset --hard <commit-id>

This changes the branch, index, and tracked files in your working tree; uncommitted tracked changes can be lost. Do not copy the placeholder literally, and do not run the command until you have verified the target and protected any work you want to keep. If you only need selected old commits, consider cherry-picking them onto a new branch instead of resetting the current one.

If the rebased branch was already pushed

Rewriting a published branch can disrupt teammates who have based work on its existing commits. Coordinate with them before replacing remote history. If restoring the old commit requires updating the remote, use your team's agreed process; do not force-push blindly. For future private-branch updates, see how to use --force-with-lease safely.

Frequently asked questions

Can I use git rebase --abort after the rebase finishes?

No. Abort is for a rebase that is currently in progress. After a completed rebase, use the reflog to find and verify the prior commit.

Does the reflog keep old commits forever?

No. Reflog entries are local and expire according to Git's maintenance settings. Recover the commit promptly and create a branch to preserve it. The reflog is useful, but it is not a substitute for a backup.