Git’s Magic Undo Button: Recovering Lost Commits

The Panic is Real

You've been working on a feature branch for two days. You just did an interactive rebase to clean up your commits. Something went wrong. Now your git log looks empty and your work is gone.

Or maybe you used git reset --hard to get rid of some changes but you went back too far. The commits you wanted to keep have vanished.

This is a terrible feeling. It feels like hours or days of work just evaporated. But with Git that work is almost never truly gone. It’s just unreferenced. And there’s a command that lets you find it.

That command is git reflog.

What is the Reflog?

Most people learn git log. It shows you the commit history of your current branch. It’s a clean linear story of how the project got to its current state.

The reflog is different. It’s messy. It’s a private diary of everything you’ve done in your local repository. Every time you switch branches checkout a commit create a branch or reset your state Git records it in the reflog. It’s a log of where HEAD has been.

To see it just type:

git reflog

You’ll get a list that looks something like this:

a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
k1l2m3n HEAD@{3}: checkout: moving from main to new-feature

Each line shows a commit hash a reference like HEAD@{1} and the action that got you there. This log is your safety net. It knows where you've been even if git log has forgotten.

Scenario 1: Recovering from a Bad Reset

Let’s walk through the most common disaster. You have a few new commits on your branch.

# Let’s say our git log looks like this
git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Now you decide to undo those last two commits. You use the big hammer git reset --hard.

# Go back to the initial commit
git reset --hard p4q5r6s

You check your log again.

git log --oneline
p4q5r6s (HEAD -> my-feature, main) Initial project setup

The commits f4e5d6c and g7h8i9j are gone. Your work has vanished. This is the moment of panic.

Don’t panic. Use the reflog.

git reflog

The output will show you the truth.

p4q5r6s HEAD@{0}: reset: moving to p4q5r6s
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
...

Look at that. f4e5d6c is right there at HEAD@{1}. This was the tip of your branch before you ran the reset command. Your work is safe.

To get it back all you have to do is reset your branch to point to that commit again.

# Restore the branch to its previous state
git reset --hard f4e5d6c

Check your log one more time.

git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Everything is back. Crisis averted.

Scenario 2: Recovering a Deleted Branch

Another common mistake is deleting a branch before you meant to. Maybe you merged it and deleted it but then realized you needed to make a small change. Or you deleted it by accident with git branch -D.

Let’s say you were on a branch called fix-auth-bug and you deleted it.

# You’re on main now
git checkout main

# You delete the branch forcefully
git branch -D fix-auth-bug

The branch is gone. How do you find the work you did on it? Again the reflog has the answer.

git reflog

Somewhere in that list you will see the last commit you made on that branch or the last time you checked out that branch.

...
a9b8c7d HEAD@{4}: commit: Fix token expiration issue
e6f5g4h HEAD@{5}: checkout: moving from main to fix-auth-bug
...

The line commit: Fix token expiration issue at commit a9b8c7d looks like the one we want. That was the last thing we did on the branch before we deleted it.

We can get it back by simply creating a new branch from that commit hash.

# Create a new branch pointing to the lost commit
git checkout -b fix-auth-bug-restored a9b8c7d

And just like that you are on a new branch with all your lost work intact. You can rename it back to the original name if you want.

A Local Safety Net

There are two important things to remember about the reflog.

First it is local to your repository. It tracks your movements on your machine. It is not pushed to the remote and your colleagues do not have your reflog. This means it can’t save them from a bad force push you made. But it can help you fix your local repository so you can force push again with the correct history. This is where it can be a lifesaver after a messy interactive rebase which you can learn more about in A Simple Workflow for Clean Git History.

Second the reflog is not permanent. Git cleans up old entries. By default they expire after 90 days. So it’s a tool for fixing recent mistakes not for long term archiving.

Understanding git reflog should give you confidence. It removes the fear of messing up your repository because you know there is almost always a way to undo a mistake. It encourages you to use powerful commands like rebase and reset knowing you have a safety net.

---

---

description: 'Git''s Magic Undo Button: Recovering Lost Commits' date: September 2025 created: 2025-09-25T17:20:59.000Z publish: true

The Panic is Real

You've been working on a feature branch for two days. You just did an interactive rebase to clean up your commits. Something went wrong. Now your git log looks empty and your work is gone.

Or maybe you used git reset --hard to get rid of some changes but you went back too far. The commits you wanted to keep have vanished.

This is a terrible feeling. It feels like hours or days of work just evaporated. But with Git that work is almost never truly gone. It’s just unreferenced. And there’s a command that lets you find it.

That command is git reflog.

What is the Reflog?

Most people learn git log. It shows you the commit history of your current branch. It’s a clean linear story of how the project got to its current state.

The reflog is different. It’s messy. It’s a private diary of everything you’ve done in your local repository. Every time you switch branches checkout a commit create a branch or reset your state Git records it in the reflog. It’s a log of where HEAD has been.

To see it just type:

git reflog

You’ll get a list that looks something like this:

a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
k1l2m3n HEAD@{3}: checkout: moving from main to new-feature

Each line shows a commit hash a reference like HEAD@{1} and the action that got you there. This log is your safety net. It knows where you've been even if git log has forgotten.

Scenario 1: Recovering from a Bad Reset

Let’s walk through the most common disaster. You have a few new commits on your branch.

# Let’s say our git log looks like this
git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Now you decide to undo those last two commits. You use the big hammer git reset --hard.

# Go back to the initial commit
git reset --hard p4q5r6s

You check your log again.

git log --oneline
p4q5r6s (HEAD -> my-feature, main) Initial project setup

The commits f4e5d6c and g7h8i9j are gone. Your work has vanished. This is the moment of panic.

Don’t panic. Use the reflog.

git reflog

The output will show you the truth.

p4q5r6s HEAD@{0}: reset: moving to p4q5r6s
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
...

Look at that. f4e5d6c is right there at HEAD@{1}. This was the tip of your branch before you ran the reset command. Your work is safe.

To get it back all you have to do is reset your branch to point to that commit again.

# Restore the branch to its previous state
git reset --hard f4e5d6c

Check your log one more time.

git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Everything is back. Crisis averted.

Scenario 2: Recovering a Deleted Branch

Another common mistake is deleting a branch before you meant to. Maybe you merged it and deleted it but then realized you needed to make a small change. Or you deleted it by accident with git branch -D.

Let’s say you were on a branch called fix-auth-bug and you deleted it.

# You’re on main now
git checkout main

# You delete the branch forcefully
git branch -D fix-auth-bug

The branch is gone. How do you find the work you did on it? Again the reflog has the answer.

git reflog

Somewhere in that list you will see the last commit you made on that branch or the last time you checked out that branch.

...
a9b8c7d HEAD@{4}: commit: Fix token expiration issue
e6f5g4h HEAD@{5}: checkout: moving from main to fix-auth-bug
...

The line commit: Fix token expiration issue at commit a9b8c7d looks like the one we want. That was the last thing we did on the branch before we deleted it.

We can get it back by simply creating a new branch from that commit hash.

# Create a new branch pointing to the lost commit
git checkout -b fix-auth-bug-restored a9b8c7d

And just like that you are on a new branch with all your lost work intact. You can rename it back to the original name if you want.

A Local Safety Net

There are two important things to remember about the reflog.

First it is local to your repository. It tracks your movements on your machine. It is not pushed to the remote and your colleagues do not have your reflog. This means it can’t save them from a bad force push you made. But it can help you fix your local repository so you can force push again with the correct history. This is where it can be a lifesaver after a messy interactive rebase which you can learn more about in A Simple Workflow for Clean Git History.

Second the reflog is not permanent. Git cleans up old entries. By default they expire after 90 days. So it’s a tool for fixing recent mistakes not for long term archiving.

Understanding git reflog should give you confidence. It removes the fear of messing up your repository because you know there is almost always a way to undo a mistake. It encourages you to use powerful commands like rebase and reset knowing you have a safety net.

Go ahead and try to describe a Git mistake you recovered from yourself.

---

---

description: 'Git''s Magic Undo Button: Recovering Lost Commits' date: September 2025 created: 2025-09-25T17:20:59.000Z publish: true

The Panic is Real

You've been working on a feature branch for two days. You just did an interactive rebase to clean up your commits. Something went wrong. Now your git log looks empty and your work is gone.

Or maybe you used git reset --hard to get rid of some changes but you went back too far. The commits you wanted to keep have vanished.

This is a terrible feeling. It feels like hours or days of work just evaporated. But with Git that work is almost never truly gone. It’s just unreferenced. And there’s a command that lets you find it.

That command is git reflog.

What is the Reflog?

Most people learn git log. It shows you the commit history of your current branch. It’s a clean linear story of how the project got to its current state.

The reflog is different. It’s messy. It’s a private diary of everything you’ve done in your local repository. Every time you switch branches checkout a commit create a branch or reset your state Git records it in the reflog. It’s a log of where HEAD has been.

To see it just type:

git reflog

You’ll get a list that looks something like this:

a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
k1l2m3n HEAD@{3}: checkout: moving from main to new-feature

Each line shows a commit hash a reference like HEAD@{1} and the action that got you there. This log is your safety net. It knows where you've been even if git log has forgotten.

Scenario 1: Recovering from a Bad Reset

Let’s walk through the most common disaster. You have a few new commits on your branch.

# Let’s say our git log looks like this
git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Now you decide to undo those last two commits. You use the big hammer git reset --hard.

# Go back to the initial commit
git reset --hard p4q5r6s

You check your log again.

git log --oneline
p4q5r6s (HEAD -> my-feature, main) Initial project setup

The commits f4e5d6c and g7h8i9j are gone. Your work has vanished. This is the moment of panic.

Don’t panic. Use the reflog.

git reflog

The output will show you the truth.

p4q5r6s HEAD@{0}: reset: moving to p4q5r6s
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
...

Look at that. f4e5d6c is right there at HEAD@{1}. This was the tip of your branch before you ran the reset command. Your work is safe.

To get it back all you have to do is reset your branch to point to that commit again.

# Restore the branch to its previous state
git reset --hard f4e5d6c

Check your log one more time.

git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Everything is back. Crisis averted.

Scenario 2: Recovering a Deleted Branch

Another common mistake is deleting a branch before you meant to. Maybe you merged it and deleted it but then realized you needed to make a small change. Or you deleted it by accident with git branch -D.

Let’s say you were on a branch called fix-auth-bug and you deleted it.

# You’re on main now
git checkout main

# You delete the branch forcefully
git branch -D fix-auth-bug

The branch is gone. How do you find the work you did on it? Again the reflog has the answer.

git reflog

Somewhere in that list you will see the last commit you made on that branch or the last time you checked out that branch.

...
a9b8c7d HEAD@{4}: commit: Fix token expiration issue
e6f5g4h HEAD@{5}: checkout: moving from main to fix-auth-bug
...

The line commit: Fix token expiration issue at commit a9b8c7d looks like the one we want. That was the last thing we did on the branch before we deleted it.

We can get it back by simply creating a new branch from that commit hash.

# Create a new branch pointing to the lost commit
git checkout -b fix-auth-bug-restored a9b8c7d

And just like that you are on a new branch with all your lost work intact. You can rename it back to the original name if you want.

A Local Safety Net

There are two important things to remember about the reflog.

First it is local to your repository. It tracks your movements on your machine. It is not pushed to the remote and your colleagues do not have your reflog. This means it can’t save them from a bad force push you made. But it can help you fix your local repository so you can force push again with the correct history. This is where it can be a lifesaver after a messy interactive rebase which you can learn more about in A Simple Workflow for Clean Git History.

Second the reflog is not permanent. Git cleans up old entries. By default they expire after 90 days. So it’s a tool for fixing recent mistakes not for long term archiving.

Understanding git reflog should give you confidence. It removes the fear of messing up your repository because you know there is almost always a way to undo a mistake. It encourages you to use powerful commands like rebase and reset knowing you have a safety net.

Go ahead and try to describe a Git mistake you recovered from yourself.

---

---

description: 'Git''s Magic Undo Button: Recovering Lost Commits' date: September 2025 created: 2025-09-25T17:20:59.000Z publish: true

The Panic is Real

You've been working on a feature branch for two days. You just did an interactive rebase to clean up your commits. Something went wrong. Now your git log looks empty and your work is gone.

Or maybe you used git reset --hard to get rid of some changes but you went back too far. The commits you wanted to keep have vanished.

This is a terrible feeling. It feels like hours or days of work just evaporated. But with Git that work is almost never truly gone. It’s just unreferenced. And there’s a command that lets you find it.

That command is git reflog.

What is the Reflog?

Most people learn git log. It shows you the commit history of your current branch. It’s a clean linear story of how the project got to its current state.

The reflog is different. It’s messy. It’s a private diary of everything you’ve done in your local repository. Every time you switch branches checkout a commit create a branch or reset your state Git records it in the reflog. It’s a log of where HEAD has been.

To see it just type:

git reflog

You’ll get a list that looks something like this:

a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
k1l2m3n HEAD@{3}: checkout: moving from main to new-feature

Each line shows a commit hash a reference like HEAD@{1} and the action that got you there. This log is your safety net. It knows where you've been even if git log has forgotten.

Scenario 1: Recovering from a Bad Reset

Let’s walk through the most common disaster. You have a few new commits on your branch.

# Let’s say our git log looks like this
git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Now you decide to undo those last two commits. You use the big hammer git reset --hard.

# Go back to the initial commit
git reset --hard p4q5r6s

You check your log again.

git log --oneline
p4q5r6s (HEAD -> my-feature, main) Initial project setup

The commits f4e5d6c and g7h8i9j are gone. Your work has vanished. This is the moment of panic.

Don’t panic. Use the reflog.

git reflog

The output will show you the truth.

p4q5r6s HEAD@{0}: reset: moving to p4q5r6s
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
...

Look at that. f4e5d6c is right there at HEAD@{1}. This was the tip of your branch before you ran the reset command. Your work is safe.

To get it back all you have to do is reset your branch to point to that commit again.

# Restore the branch to its previous state
git reset --hard f4e5d6c

Check your log one more time.

git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Everything is back. Crisis averted.

Scenario 2: Recovering a Deleted Branch

Another common mistake is deleting a branch before you meant to. Maybe you merged it and deleted it but then realized you needed to make a small change. Or you deleted it by accident with git branch -D.

Let’s say you were on a branch called fix-auth-bug and you deleted it.

# You’re on main now
git checkout main

# You delete the branch forcefully
git branch -D fix-auth-bug

The branch is gone. How do you find the work you did on it? Again the reflog has the answer.

git reflog

Somewhere in that list you will see the last commit you made on that branch or the last time you checked out that branch.

...
a9b8c7d HEAD@{4}: commit: Fix token expiration issue
e6f5g4h HEAD@{5}: checkout: moving from main to fix-auth-bug
...

The line commit: Fix token expiration issue at commit a9b8c7d looks like the one we want. That was the last thing we did on the branch before we deleted it.

We can get it back by simply creating a new branch from that commit hash.

# Create a new branch pointing to the lost commit
git checkout -b fix-auth-bug-restored a9b8c7d

And just like that you are on a new branch with all your lost work intact. You can rename it back to the original name if you want.

A Local Safety Net

There are two important things to remember about the reflog.

First it is local to your repository. It tracks your movements on your machine. It is not pushed to the remote and your colleagues do not have your reflog. This means it can’t save them from a bad force push you made. But it can help you fix your local repository so you can force push again with the correct history. This is where it can be a lifesaver after a messy interactive rebase which you can learn more about in A Simple Workflow for Clean Git History.

Second the reflog is not permanent. Git cleans up old entries. By default they expire after 90 days. So it’s a tool for fixing recent mistakes not for long term archiving.

Understanding git reflog should give you confidence. It removes the fear of messing up your repository because you know there is almost always a way to undo a mistake. It encourages you to use powerful commands like rebase and reset knowing you have a safety net.

Go ahead and try to describe a Git mistake you recovered from yourself.

---

---

description: 'Git''s Magic Undo Button: Recovering Lost Commits' date: September 2025 created: 2025-09-25T17:20:59.000Z publish: true

The Panic is Real

You've been working on a feature branch for two days. You just did an interactive rebase to clean up your commits. Something went wrong. Now your git log looks empty and your work is gone.

Or maybe you used git reset --hard to get rid of some changes but you went back too far. The commits you wanted to keep have vanished.

This is a terrible feeling. It feels like hours or days of work just evaporated. But with Git that work is almost never truly gone. It’s just unreferenced. And there’s a command that lets you find it.

That command is git reflog.

What is the Reflog?

Most people learn git log. It shows you the commit history of your current branch. It’s a clean linear story of how the project got to its current state.

The reflog is different. It’s messy. It’s a private diary of everything you’ve done in your local repository. Every time you switch branches checkout a commit create a branch or reset your state Git records it in the reflog. It’s a log of where HEAD has been.

To see it just type:

git reflog

You’ll get a list that looks something like this:

a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
k1l2m3n HEAD@{3}: checkout: moving from main to new-feature

Each line shows a commit hash a reference like HEAD@{1} and the action that got you there. This log is your safety net. It knows where you've been even if git log has forgotten.

Scenario 1: Recovering from a Bad Reset

Let’s walk through the most common disaster. You have a few new commits on your branch.

# Let’s say our git log looks like this
git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Now you decide to undo those last two commits. You use the big hammer git reset --hard.

# Go back to the initial commit
git reset --hard p4q5r6s

You check your log again.

git log --oneline
p4q5r6s (HEAD -> my-feature, main) Initial project setup

The commits f4e5d6c and g7h8i9j are gone. Your work has vanished. This is the moment of panic.

Don’t panic. Use the reflog.

git reflog

The output will show you the truth.

p4q5r6s HEAD@{0}: reset: moving to p4q5r6s
f4e5d6c HEAD@{1}: commit: Add final touches to feature
g7h8i9j HEAD@{2}: commit: Implement core feature logic
...

Look at that. f4e5d6c is right there at HEAD@{1}. This was the tip of your branch before you ran the reset command. Your work is safe.

To get it back all you have to do is reset your branch to point to that commit again.

# Restore the branch to its previous state
git reset --hard f4e5d6c

Check your log one more time.

git log --oneline
f4e5d6c (HEAD -> my-feature) Add final touches to feature
g7h8i9j Implement core feature logic
p4q5r6s (main) Initial project setup

Everything is back. Crisis averted.

Scenario 2: Recovering a Deleted Branch

Another common mistake is deleting a branch before you meant to. Maybe you merged it and deleted it but then realized you needed to make a small change. Or you deleted it by accident with git branch -D.

Let’s say you were on a branch called fix-auth-bug and you deleted it.

# You’re on main now
git checkout main

# You delete the branch forcefully
git branch -D fix-auth-bug

The branch is gone. How do you find the work you did on it? Again the reflog has the answer.

git reflog

Somewhere in that list you will see the last commit you made on that branch or the last time you checked out that branch.

...
a9b8c7d HEAD@{4}: commit: Fix token expiration issue
e6f5g4h HEAD@{5}: checkout: moving from main to fix-auth-bug
...

The line commit: Fix token expiration issue at commit a9b8c7d looks like the one we want. That was the last thing we did on the branch before we deleted it.

We can get it back by simply creating a new branch from that commit hash.

# Create a new branch pointing to the lost commit
git checkout -b fix-auth-bug-restored a9b8c7d

And just like that you are on a new branch with all your lost work intact. You can rename it back to the original name if you want.

A Local Safety Net

There are two important things to remember about the reflog.

First it is local to your repository. It tracks your movements on your machine. It is not pushed to the remote and your colleagues do not have your reflog. This means it can’t save them from a bad force push you made. But it can help you fix your local repository so you can force push again with the correct history. This is where it can be a lifesaver after a messy interactive rebase which you can learn more about in A Simple Workflow for Clean Git History.

Second the reflog is not permanent. Git cleans up old entries. By default they expire after 90 days. So it’s a tool for fixing recent mistakes not for long term archiving.

Understanding git reflog should give you confidence. It removes the fear of messing up your repository because you know there is almost always a way to undo a mistake. It encourages you to use powerful commands like rebase and reset knowing you have a safety net.

Go ahead and try to describe a Git mistake you recovered from yourself.

— Rishi Banerjee
September 2025