What is the easiest, quick and foolproof way to undo a git rebase?

Question

I am new to Git rebasing and want to be able to revert a rebase completely and easily. I found solutions that involve several steps and use advanced commands like git reflog. I am afraid I won't be able to apply those correctly and/or will need a lot of time to figure out what exactly to do.

Is there an easy, quick and foolproof solution, even if it's "dumb"?

My own "dumb" solution: Duplicate the project folder on a file system level and then after a "failed" rebase just delete the original folder and rename the backup to the originals name.

Answer 1

The reference, "ORIG_HEAD" stores the previous HEAD commit and will undo a rebase or a merge.

git reset --hard ORIG_HEAD

From the documentation:

ORIG_HEAD is created by commands that move your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them

The documentation suggests it's designed for this specific purpose.

Answer 2

before doing a rebase push your current work to your git server (github etc).

then you can safely rebase and if you want to revert you can just delete the folder and clone it from the server. or reset to the upstream head.

Answer 3

As long as this is purely local, that is, you're not pushing your branch between rebasing and potentially reverting, just start out by creating an additional backup branch, at the same commit as you are rebasing from. That branch will then stay the same, and you can just reset to that, should something go wrong. And the backup branch will stay around until you specifically delete it.

Create the backup branch with:

git branch backup 

Then do the rebase:

git rebase <branch-to-rebase-on>

If you want to revert after the rebase is completed, just do:

git reset --hard backup

This will reset your current branch to the same commit as backup, which is where you started out before the rebase. Note that any changes or new commits made will be discarded though!

If you find out during the rebase (while fixing conflicts for instance), that you want to cancel the rebase, you can always do:

git rebase --abort

Answer 4

If you do use ORIG_HEAD to reset and cancel a rebase, make sure to use a Git 2.22 (Q2 2019)

"git rebase" that was reimplemented in C did not set ORIG_HEAD correctly, which has been corrected.

See commit cbd29ea, commit c2d9629, commit eaf8160, commit e6aac81 (03 Mar 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 9fbcc3d, 20 Mar 2019)}

built-in rebase: set ORIG_HEAD just once, before the rebase

Technically, the scripted version set ORIG_HEAD only in two spots (which really could have been one, because it called git checkout $onto^0 to start the rebase and also if it could take a shortcut, and in both cases it called git update-ref $orig_head).

Practically, it implicitly reset ORIG_HEAD whenever git reset --hard was called.

However, what we really want is that it is set exactly once, at the beginning of the rebase.

So let's do that.

built-in rebase: no need to check out onto twice

In the case that the rebase boils down to a fast-forward, the built-in rebase reset the working tree twice:

• once to start the rebase at onto,
• then realizing that the original (pre-rebase) HEAD was an ancestor and we basically already fast-forwarded to the post-rebase HEAD, reset_head() was called to update the original ref and to point HEAD back to it.

That second reset_head() call does not need to touch the working tree, though, as it does not change the actual tip commit (and therefore the working tree should stay unchanged anyway): only the ref needs to be updated (because the rebase detached the HEAD, and we want to go back to the branch on which the rebase was started).