How I Recovered 21 Git Commits I Accidentally Lost

There are moments in every developer’s journey that make your heart skip a beat. For me, this happened when I thought I had lost 21 commits—around 15 days of work—with a single Git reset command.

Fortunately, Git had my back.

Here’s what happened and how I recovered everything.

What happened

I maintain a WordPress plugin that, until now, I had been developing directly on the main branch. Since I’m the only person maintaining this repository, that workflow had always worked fine.

Recently, I decided to improve my development process. Instead of committing everything directly to main, I wanted to start using GitHub Issues and feature branches so that every change would have proper context and history.

I had already completed around 21 commits locally on my main branch. Before pushing them, I created a GitHub issue and then created a new branch for that issue.

Everything looked normal, so I pushed my changes.

Where I Got Confused

After pushing, I opened GitHub and noticed that both the main branch and my newly created feature branch appeared to have no differences. I misunderstood what I was seeing. I assumed that my commits had somehow been pushed to both branches, so I thought I needed to remove those commits from main.

Back on my local machine, I switched to the main branch and removed the commits using git reset --hard HEAD~21.

Within seconds, my branch history had moved back, and my 21 commits disappeared & those were not present on my issue branch. That moment was pure panic. Fifteen days of work appeared to be gone.

The Recovery

After taking a moment to think, I remembered that Git keeps a history of where HEAD has been, even after a hard reset.

The first command I ran was:

git reflog

The reflog showed every movement of HEAD, including my reset commands. After carefully reading the output, I found the commit hash that represented the last commit before I accidentally reset my branch.

Instead of immediately resetting anything again, I first created a recovery branch pointing to that commit:

git switch -c recovery-21-commits <commit-id>

This gave me a safe copy of all my work.

Next, I switched back to my feature branch:

git switch 1-implement-availability-notifications-automatic-class-cleanup

Then I restored the branch to the recovered commit:

git reset --hard <commit-id>

Finally, I verified everything by checking the commit history:

git log --oneline --graph

There they were.

All 21 commits.

My entire history was back exactly as it had been before the mistake.

What I Learned

This experience taught me a few valuable lessons:

• git reset --hard moves your branch pointer, but it doesn’t immediately destroy your commits.
• git reflog is one of the most valuable recovery tools in Git.
• Before running destructive Git commands, it’s worth taking a minute to understand exactly what they will do.
• Creating a recovery branch before attempting any fixes gives you a safe place to work from.
• Just because GitHub shows “no differences” doesn’t necessarily mean your commits exist on multiple branches. Understanding branch pointers is important.

Final Thoughts

For about ten minutes, I genuinely believed I had lost two weeks of work.

Thankfully, Git’s reflog saved me.

If you ever find yourself in a similar situation after accidentally using git reset --hard, don’t panic. Before trying random commands, run:

git reflog

Your commits may still be there, waiting to be recovered.

Sometimes the best Git lessons are the ones you learn the hard way. This was definitely one of mine.