How to undo git reset --hard safely

The short answer

Find where HEAD was before the reset, verify it, and give the commit a rescue branch before moving anything.

git reflog
# Find the line for the state you want, e.g. HEAD@{1}
git show HEAD@{1}
git branch rescue-lost-work HEAD@{1}
# Optional, after verification:
git reset --hard HEAD@{1}

HEAD@{1} means "where HEAD pointed one move ago" and is often the right entry immediately after a reset. It is not guaranteed: another checkout, reset, rebase, or commit may have added reflog entries. Read the message, inspect the commit, and use its SHA if that is clearer. One important caveat decides whether the rest of this article can help you.

Can you revert git reset --hard?

Yes, when the lost work was committed and its object still exists, but git revert is usually not the command you need. Revert creates a new commit that reverses the changes introduced by an existing commit; it does not move a branch back to the position it had before a reset. Use git reflog to find that position, verify it, and create a rescue branch first.

Git also writes the old branch tip to ORIG_HEAD before a reset, so git show ORIG_HEAD may point straight to the lost commit. Other Git commands can overwrite ORIG_HEAD, which makes the reflog the better record. Verify either reference before creating the rescue branch.

Committed work versus uncommitted work

Reflog recovers commits. If the work you lost was committed before the reset and its object is still retained, the steps below can help you recover it. If the work was never committed, only staged or edited in the working tree, then git reset --hard overwrote those files and the reflog has nothing to offer, because there was no commit to point at.

There is a partial exception: content that was ever staged with git add exists as a loose object in the repository, and git fsck --lost-found can sometimes surface it. That path is covered in the companion guide linked at the end. For committed work, keep reading.

Step by step

Before anything, stop running commands that move refs. Every extra reset, rebase, or checkout adds noise to the reflog and can push the entry you need further down. Inspect first, act once.

Choose the recovery path by what was saved

The full sequence

Here is a complete, safe recovery. It looks at the reflog, verifies the commit, and rescues it into a branch instead of resetting in place, so a wrong guess costs nothing:

$ git reflog
9b7c4e2 HEAD@{0}: reset: moving to HEAD~3
4d3a1f8 HEAD@{1}: commit: add checkout validation
a1b2c3d HEAD@{2}: commit: wire payment provider
...

# Verify HEAD@{1} is the work you want
$ git show HEAD@{1}

# Rescue it into a branch without touching your current one
$ git branch rescue-lost-work HEAD@{1}

# When you are sure, move your branch back
$ git reset --hard HEAD@{1}

If you would rather just jump straight back and skip the rescue branch, git reset --hard HEAD@{1} on its own is enough. The rescue branch only exists so that a mistaken reset has an undo of its own.

What reset --hard actually did

git reset --hard <target> does three things: it moves the current branch to <target>, it makes the index match, and it overwrites the working tree to match. The commits you moved away from are not deleted immediately. The default reflog expiry is 90 days for reachable entries and 30 days for entries that are no longer reachable. Object pruning is a separate process, with its own default grace period of two weeks. Configuration and manual garbage collection can change both, so recover the commit promptly.

Official Git references

These steps follow the official documentation for git reset and ORIG_HEAD, reflog expiry, git revert, and garbage collection and pruning.

What reflog does not guarantee

The reflog is local to your clone and time-limited. It does not exist on a fresh clone, it is pruned over time, and it cannot restore working-tree edits that were never committed or staged. If you have already run git gc --prune=now after the reset, the objects may be gone for good. Treat reflog as a strong safety net, not a backup system.

Watch: recover a retained commit after a hard reset

See a committed change disappear from a branch after a reset, then recover it on a rescue branch using the local reflog. The commit object must still be retained; reflog expiry and object cleanup can prevent recovery.

Watch on YouTube — opens a new tab

Recorded in a test repository. Uncommitted working-tree edits are not in the reflog. With restore points enabled and local changes detected, FluxGit can save a safety stash before a hard reset in the app. The plain Git terminal reset shown here does not use that protection.