Every Way to Undo, and Which One You Want

This chapter exists because searching for "git undo" turns up long answers listing many commands side by side, and running the wrong one of them destroys work.

The reliable method is to stop and say out loud what you want to lose. There are only six answers, and each has exactly one right command.

git restore overwrites a file in your working tree with the version in the index — which is the last commit, unless you had staged a newer version. Whatever you had typed is gone — not in the index, not in a commit, not in the reflog. Gone.

$ git restore src/app.js       # this file, back to its staged/committed version$ git restore .                 # every modified file. There is no confirmation prompt.

There is no undo for this because there is nothing to undo from. Git can recover anything it has ever recorded, and it never recorded that edit.

If you are not sure you want to lose it, do not. git stash sets your changes aside somewhere you can get them back.

$ git stash push -m "half-finished search filter"# working tree is clean now $ git stash list                # what is stashed$ git stash pop                 # bring the most recent one back and remove it from the stash$ git stash apply stash@{1}     # bring an older one back and KEEP it in the stash

git reset does one thing: it points your current branch at a different commit. What it does to your files afterwards is decided entirely by which of three flags you pass, and those three flags are the whole difficulty.

# "I want to redo the last commit differently"$ git reset --soft HEAD~1# ... adjust what is staged ...$ git commit -m "The message and contents I actually meant" # "Uncommit the last three, keep all the work in my folder"$ git reset HEAD~3 # "Throw the last commit away entirely, including the code"$ git reset --hard HEAD~1

HEAD~1 means "one commit before HEAD", HEAD~3 means three before, and so on. You can also give a hash directly.

git revert is the safe undo, and it is the only one that is honest about what happened. It does not remove the bad commit. It computes the opposite of that commit's diff and commits that.

$ git revert 2c7a91f            # opens an editor with a pre-written message$ git revert --no-edit 2c7a91f  # accept the default message$ git revert HEAD               # undo the very last commit, safely

* 8e2f1d5  Revert "Cache the user lookup for 60 seconds"* 2c7a91f  Cache the user lookup for 60 seconds* 1a5e8c3  Set up the router

Both commits are in the history. That is not clutter — it is the record. Anyone reading it later sees that the caching was tried and withdrawn, which is useful information and is exactly what a reset would have erased.

Every time HEAD moves — every commit, checkout, reset, merge, rebase, amend — Git writes a line to the reflog. It is local, it is not part of the history, nobody else ever sees it, and it keeps roughly ninety days.

It is how you recover from a reset --hard you should not have run.

$ git reflog

1a5e8c3 HEAD@{0}: reset: moving to HEAD~34b8e0d7 HEAD@{1}: commit: Handle the empty next param2c7a91f HEAD@{2}: commit: Fix the redirect when next is empty7d1f6b4 HEAD@{3}: commit: Add the settings page1a5e8c3 HEAD@{4}: checkout: moving from main to fix/login

1. 1

   Find where you were before the mistake

   HEAD@{1} here is the commit the branch pointed at immediately before the reset. Its hash is 4b8e0d7.

2. 2

   Look before you leap

   git show 4b8e0d7 confirms it is the commit you think it is. Cheap, and it costs nothing to check.

3. 3

   Put the branch back

   git reset --hard 4b8e0d7 moves your branch back to where it was. The three commits are exactly as they were, with the same hashes.