I ran git reset --hard HEAD on the wrong terminal tab and wiped a week’s worth of uncommitted payment logic. I spent five seconds staring at a blank screen in pure, cold panic before remembering a command most developers never touch until they’re desperate: git reflog. This isn’t just a story about how I saved my job; it’s a guide to the ultimate “undo” button in Git that tracks every move you’ve made for the last 90 days. If you’ve ever felt the stomach-drop of a lost commit, this is the one tool you need to master before your next Friday afternoon deploy.
How did I accidentally delete a week of work?
It was a Friday, and I had three terminal tabs open. I thought I was in a temp worktree, but I was actually on my main feature branch. I wanted a “clean slate” for a hotfix, ran the hard reset, and instantly realized I’d just nuked 15 files of work.
The Scenario: You’re juggling three different bugs and you’ve got five terminal tabs open. You run a command in the “wrong” tab because you’re tired, and suddenly your
git statusshows a clean directory where your whole week’s work used to be. It’s a gut-punch that every dev knows.
Is my code actually gone forever after a hard reset?
A git reset --hard feels like it’s permanent. It doesn’t ask if you’re sure; it just executes. Since the changes weren’t pushed to GitHub and your editor just reloaded the empty files, it looks like they’ve vanished into the void.
The Scenario: You’re frantically checking your editor’s undo history, but it’s empty. You check your “WIP” branch on GitHub, but you haven’t pushed in two days. You start calculating how many hours of overtime it’s going to take to rewrite everything from memory.
What is the secret history that Git keeps under the hood?
git log shows you the commits on a branch, but git reflog shows you every time your HEAD moved. It tracks checkouts, resets, commits, and merges. Even if you “deleted” a commit by resetting past it, the record of that commit still exists in the reflog for about 90 days.
The Scenario: You realize that even though your branch is “gone,” Git actually saved a snapshot of your state ten minutes ago when you made that messy “WIP” commit. The reflog is the black box flight recorder of your repository.
How do I actually find and recover my lost commits?
Running git reflog gives you a list of entries like HEAD@{0}, HEAD@{1}, and so on. You find the point right before your disastrous reset and use git reset --hard HEAD@{n} to jump back in time. Everything—your files, your logic, your sanity—comes back instantly.
The Scenario: You run the recovery command, hold your breath, and then refresh your editor. Suddenly, those 15 files reappear. You see your code exactly as it was before the panic started. You can finally breathe again.
What are the limits of the Git recovery system?
Reflog can recover anything that was committed at some point. If you had changes that were never added to the index (git add) or committed, they are truly gone. This is why you should commit early and often, even if the commit message is just “temp.”
The Scenario: You realize you had two files that you hadn’t even added to Git yet. Those files are gone forever. You’ve recovered 90% of your work, but those last two files are a painful reminder to
git addyour work as soon as it’s written.
How do I stop myself from making this mistake again?
The lesson is simple: committed is recoverable, uncommitted is not. I started committing WIP changes every hour and using git rebase -i to clean them up later. I also added my branch name to my terminal prompt so I always know where I am.
The Scenario: You’re about to run a reset, but you look at your terminal and see
[main]in bright red. You realize you’re in the wrong folder. You switch tabs, run the command safely, and avoid a heart attack. Your terminal just saved your afternoon.
Which Git commands should I memorize for emergencies?
You need to know git reflog to see the history, git reset --hard HEAD@{n} to go back, and git checkout -b recovery-branch if you want to be safer and create a new branch from a lost state instead of overwriting your current one.
The Scenario: A coworker accidentally deletes a branch they spent three days on. Instead of them panicking, you calmly walk over, run
git reflog, and recover their branch in thirty seconds. You’re now the office hero.
Why is Git not as destructive as it feels?
Git is designed to be a safety net, not a trap. Most “destructive” commands are actually just moving pointers around. The actual data stays in the .git folder for weeks before it’s “garbage collected.” Once you understand this, the terminal stops being a scary place.
The Scenario: You used to be terrified of
git rebasebecause you thought you’d lose data. Now you realize that even if you mess up a rebase, you can justreflogback to the start. You’re finally confident enough to use Git’s most powerful features.
Summary
- Reflog is King: It’s your 90-day undo button for every Git move.
- Commit Often: If it’s committed, it’s recoverable.
- Terminal Prompts: Make sure your branch name is always visible to avoid “tab confusion.”
FAQ
Does reflog work after I close my terminal?
Yes. The data is stored in your .git folder, not in your terminal’s memory.
Can reflog recover a deleted folder? Only if that folder’s contents were committed at some point.
What to Read Next:
