Git Reflog: The Art of Fixing What’s Broken

You hit enter, and then—something feels off. You check git status. Nothing. You check git log. Your commits are gone. Your heart starts pounding. You scramble, running commands, searching for a way to undo the damage.

Nothing works.

Your work—hours of effort—is gone.

But what if I told you Git never really loses anything?

Most people think once a commit is gone, it’s gone forever, but Git actually keeps a hidden record of every move you make. This secret history is called git reflog, and once you know how to use it, you’ll never fear Git again.

Let me show you four real-world scenarios where git reflog saved the day—and how it can save yours too.

Scenario 1: The Vanishing Branch

🚨 You deleted your branch… and never pushed it.

You’ve been working on a feature branch all afternoon, making commits, cleaning things up—but you haven’t pushed anything yet. Feeling confident, you decide to clean up your history with an interactive rebase.

git rebase -i HEAD~10

But something goes wrong. After resolving a few conflicts, you check git log, expecting a neat, condensed history. Instead, your commits are gone. Confused, you check out another branch, hoping to reset things, and then, in frustration, delete the feature branch entirely.

git branch -D feature-awesome

And then you remember: you never pushed this branch to the remote. It’s gone. Hours of work, just erased from existence.

💡 How git reflog saves you:

Git remembers even deleted branches. Even though the branch is gone, you can still get back the last commit you were on. Running git reflog shows a list of every action you've taken, including checkouts and deletions. You can find the last commit before the deletion and restore it.

git checkout -b feature-awesome 

Just like that, your branch is back. Git kept track of it, even when you thought it was gone forever.

Scenario 2: The Force-Push Disaster

Losing a local branch is terrifying, but losing everyone’s work is even worse. And nothing destroys a shared branch faster than a force push gone wrong.

Alex is a little too comfortable with git push --force. One day, after making some last-minute changes, they push without pulling first.

git push --force

Seconds later, Slack explodes.

“Uh… where are my commits?”

Alex just erased two days of team progress from the remote branch. Panic sets in. git log doesn’t show the old commits—they’re just gone. Everyone is looking at them, waiting for a solution.

💡 How git reflog saves you:

Even though the remote history is wiped, Git still remembers the last state before the force push. Running git reflog reveals the exact commit hash of the branch before the push. By resetting to that commit and pushing again, Alex can bring everything back.

git reset --hard 
git push --force-with-lease

Crisis averted, and Alex learns an important lesson: --force-with-lease is safer than --force because it prevents overwriting work if someone else has pushed in the meantime.

Scenario 3: The Stash That Vanished

🚨 You stashed your work… but now it’s gone.

Emma is halfway through a massive refactor when a high-priority bug report comes in. She doesn’t want to commit her unfinished changes, so she stashes them instead.

git stash
git checkout hotfix-branch

After fixing the bug, she comes back and applies the stash.

git stash pop

Boom—merge conflicts. Emma tries to fix them manually, but something goes wrong. In frustration, she aborts everything and checks out another branch, forgetting that popping a stash deletes it from the stash list. Hours later, she realizes her changes are gone.

💡 How git reflog saves you:

Stashes don’t actually disappear immediately—Git records them in the reflog. Running git reflog shows when the stash was popped and the commit it was applied to. Emma finds the stash reference and recovers it.

git checkout -b stash-recovery 

Just like that, her changes are back. Lesson learned: git stash apply is safer than git stash pop because it doesn’t delete the stash automatically.

Scenario 4: The Hard Reset Regret

🚨 You accidentally nuked your last five commits.

Max is cleaning up their commit history and wants to reset some recent changes. They miscalculate and run a hard reset.

git reset --hard HEAD~5

Five commits, gone in an instant. git log shows nothing. There’s no undo button. Max stares at the screen, realizing their mistake.

💡 How git reflog saves you:

Hard resets feel permanent—but they aren’t. git reflog still remembers the previous state of HEAD, even after a reset. Running git reflog, Max finds the last commit before the reset and restores it.

git reset --hard 

Disaster averted.

How to Travel Back in Time with Git Reflog

Once you understand git reflog, you can do some crazy powerful things with Git’s history.

• Checkout the exact state of your branch from three hours ago.

git checkout HEAD@{3.hours.ago}

• Compare your current branch to how it looked yesterday.
  

git diff HEAD@{0} HEAD@{1.day.ago}

• Undo your last checkout (if you switched branches by accident).
  

git checkout @{-1}

• Find the commit where you last rebased.
  

git reflog | grep rebase

Final Thoughts: Git Never Really Loses Anything

Most people think of Git as a version control system, but it’s really a time machine. Every commit, checkout, reset, and rebase is logged somewhere. If you know where to look, Git never forgets.

The next time you make a mistake, don’t panic.

• Deleted a branch? git reflog.
  
• Force-pushed something bad? git reflog.
  
• Lost a stash? git reflog.
  
• Hard reset too far? git reflog.
  

Every developer makes mistakes. The difference between panic and recovery is knowing how to undo them. Most people fear breaking things in Git. Not you. You’ve got git reflog. And now?

You can code like nothing is irreversible—because nothing is.