git reset --hardMoves the branch pointer AND resets both staging area AND working directory. Uncommitted changes are gone forever. Commits can be recovered via reflog, but unstaged and untracked work cannot.
Reflog ≠ undo buttonReflog only tracks commits and HEAD movements. If you had unstaged modifications, untracked files, or staged-but-uncommitted changes, those are NOT in the reflog. What you didn't commit, you can lose.
📖 Story
You're building a new feature. You make some edits, stage them, and feel good. Then you decide to scrap it and start over.
A clean reset seems like the right call. And it is — until it isn't.
This is the story of the difference between 'I can undo that' and 'I should have committed first.'
Modify app.py — change "v1" to "v2" in the editor, then stage it.
Open app.py in the file editor (click it in the file tree), replace v1 with v2, then run git add app.py to stage the change.
● Modify app.py — change "v1" to "v2" in the editor, then stage it.
○ Create notes.txt with content "my notes" and stage it too.
○ You decide the approach is wrong. Discard the staged changes and start fresh.
○ Check the reflog — see what happened.
○ Check git status to see the full picture.
Terminal
📘 Starting tutorial: The Reset Trap
Learn the hard way why --hard is dangerous and reflog is your safety net
Step 1: Modify app.py — change "v1" to "v2" in the editor, then stage it.