🔀 checkout — . = Uncommitted Work Gone
git checkout -- . silently discards every unstaged change in your working directory, no confirmation, no undo command — but depending on exactly what you had done before running it, some of that work may still be recoverable.
🚨 First: Know What’s Actually Recoverable
- Changes that were only in your editor and NEVER staged (git add) or saved by your IDE’s local history: usually gone for good.
- Changes you had staged at any point (even briefly) before the checkout: often recoverable from Git’s internal object store.
- Stop editing those files right now so you don’t overwrite any chance of recovery.
🔍 Recover Anything That Was Ever Staged
# Find "dangling" blobs Git hasn't garbage-collected yet -
# staged changes leave a trace here even after checkout wipes them
git fsck --no-reflog | awk '/dangling blob/ {print $3}'
# Inspect a candidate blob's content
git show <blob-sha>
# If it's what you lost, save it back to a file
git show <blob-sha> > recovered_file.txt
✅ Also Check Your Editor’s Local History
- VS Code, Rider, and Visual Studio all keep their own local edit history independent of Git — often your fastest recovery path.
- VS Code: right-click the file → “Open Timeline”; Rider/IntelliJ: right-click → Local History → Show History.
🛡️ Prevent the Next One
- Commit early and often on a scratch/WIP branch — a bad commit is trivial to undo, a lost uncommitted edit often isn’t.
- Prefer ‘git restore
<file>‘ over ‘git checkout —<file>‘ going forward: same danger, but the newer command name makes the destructive intent clearer before you hit enter. - Consider ‘git stash’ instead of discarding when you just want the working directory clean temporarily.
Git’s safety net is the commit, not the working directory — anything you haven’t committed (or at least staged once) is living on borrowed time the moment you save the file.