Undo a git reset --hard and get your commits back

Does this match your situation?

• You ran git reset --hard and commits vanished from git log.
• A branch suddenly points at a much older commit.
• You reset to the wrong commit and want to go back to where you were.

Step-by-step fix

1. Open the reflog immediately

   The reflog is a local journal of every move HEAD has made — commits, checkouts, resets, merges, rebases. Your pre-reset position is still listed there even though no branch points to it any more. Do this before running any other Git command so the entry you want stays near the top.

   step 1Copy

   git reflog
   

   ✅Output looks like: a1b2c3d HEAD@{0}: reset: moving to HEAD~3 / f4e5d6c HEAD@{1}: commit: Add save system

2. Identify the entry from just before the reset

   Read down the list until you find the reset itself — the entry directly below it is where you were standing beforehand. Confirm you've got the right one by inspecting it before you move anything.

   step 2Copy

   git show HEAD@{1}
   git log HEAD@{1} --oneline -5
   

3. Move your branch back to that commit

   Once you're sure, point the branch at the recovered commit. Using the explicit hash rather than HEAD@{1} is safer, because the reflog shifts every time HEAD moves.

   step 3Copy

   git reset --hard f4e5d6c
   

   ⚠️Prefer the raw hash over HEAD@{1} — the numbering changes as soon as you run another command.

4. Or recover onto a fresh branch instead

   If you'd rather not disturb the current branch, create a new one at the lost commit. This is the risk-free option: nothing you already have moves, and you can compare the two before deciding.

   step 4Copy

   git branch recovered-work f4e5d6c
   git switch recovered-work
   

Why this works

git reset --hard doesn't delete commits — it only moves a branch pointer and overwrites your working directory. The commits it moved away from remain in .git/objects, unreferenced but intact. The reflog keeps a record of every value each reference has held, for 90 days by default, which is exactly the map you need to point a branch back at them. The part reset --hard genuinely destroys is uncommitted working-directory content, because that was never written to the object database in the first place — unless you had staged it, in which case a dangling blob survives.

If that didn’t work

• If the reflog is empty or missing the entry, run git fsck --lost-found and look through the dangling commits.
• Check whether the commits were ever pushed — git fetch origin and look at origin/your-branch.
• Look for the work in another clone, a CI job's checkout, or a colleague's fetch of your branch.

How to stop it happening again

• Use git reset --keep instead of --hard: it refuses to run if it would overwrite uncommitted changes.
• Commit or stash before any reset — then the worst case is a one-line reflog fix.
• Create a throwaway safety branch before risky operations: git branch backup-before-rebase.

Commands used in this guide

Frequently asked questions