A walkthrough of the Recover Lost Commits tutorial: how git reset --hard can seem to delete a commit, and how git reflog finds it again so you can restore it.
This scenario teaches the most reassuring fact in Git: a commit you "lost" with git reset --hard is usually still there. You will see the commit vanish from the history, then bring it back with git reflog.
The situation
Git links every commit to its parent and stores it by hash, so nothing is truly deleted.
The project has three commits: Initial commit, Add header navigation, and Add skills section. After a git reset --hard that went one step too far, the latest commit no longer shows up in git log. It looks deleted.
It is not. Resetting moved the branch pointer back, leaving the Add skills section commit in place but unreferenced. Git still remembers it.
git reset --hard discards working changes and moves the branch, which is why it feels destructive. The commit object survives, but the only easy way back is through the reflog.
The recovery, step by step
Once git reflog gives you the hash, point a branch back at it to recover the commit.
See that the commit is missing
git log
The log now ends at Add header navigation. The skills commit is gone from this view, which is the symptom you are recovering from.
Find it in the reflog
git reflog
The reflog lists every move HEAD made, including the Add skills section commit before the reset. Note its hash (or its HEAD@{n} reference).
Restore the branch to that commit
git reset --hard <commit-hash>
Pointing the branch back at the lost commit's hash brings Add skills section back into git log. The history is whole again.
Why the commit was recoverable
A commit survives as long as something references it, which is why the reflog can bring it back.
git log and git reflog answer different questions:
git log shows commits reachable from the current branch. A reset removes the commit from that chain, so it disappears here.
git reflog shows everywhere HEAD has been, branch or not. The lost commit is still listed, with the hash you need to return to it.
You can copy either the raw hash or the HEAD@{1} style reference from the reflog. Both work with git reset --hard.
The reflog is local to your clone. It is a personal safety net, not something shared with the remote, so it is always there for your own mistakes.
Recovering different kinds of lost work
git reflog is the first stop for almost any "I lost it" moment, because it records every position HEAD has held:
- After
git reset --hard — find the commit in git reflog, then git reset --hard <hash> to return to it (or git checkout <hash> to look first).
- A deleted branch — its tip is still in the reflog; recreate it with
git branch <name> <hash>.
- A bad rebase or amend — the pre-rebase commits are in the reflog; reset back to the entry from before it ran.
- When the reflog no longer has it — entries expire (about 90 days by default, or after
git gc). git fsck --lost-found can sometimes still surface dangling commits.
Try it here: make a commit, reset --hard it away, then bring it back from the reflog. Once you have done it, reset --hard stops being scary.