Recovering Deleted Commits: Mastering Git Reflog for Safety

Previously in this course, we covered squashing commits to maintain a clean project history. While history manipulation is powerful, it carries risks—sometimes, you might delete a commit or reset a branch too aggressively, making your work seem to vanish.

In this lesson, we add a critical safety net to your workflow: the git reflog. This tool acts as a "black box" flight recorder for your local repository, allowing for recovery when things go wrong.

Understanding the Git Reflog from First Principles

In Git, objects like commits are never truly deleted the moment you run a command like git reset --hard. Instead, they become "dangling"—they are no longer reachable from any branch or tag, but the data remains in your local database until Git's garbage collection clears it (usually after 30 days).

The git reflog (reference log) tracks every movement of HEAD in your local repository. Unlike git log, which shows the history of your project, the reflog shows the history of your actions within that repository. It records every time you commit, checkout, merge, or reset.

Why the Reflog is Your Safety Net

Whenever you perform an operation that changes the state of a branch, Git updates the reflog. This is why you can often recover "lost" work: even if you delete a branch or reset to an old commit, the specific hash of that "lost" commit is still sitting safely in your reflog.

Worked Example: Recovering a "Deleted" Commit

Imagine you have been working on our project’s documentation, but you accidentally performed a hard reset that wiped out your latest changes.

1. The Accident: You run git reset --hard HEAD~1 to undo the last commit, forgetting that you hadn't pushed it to GitHub yet. Your work is now "gone" from your git log.

2. The Recovery: Open your terminal and type:

   Bash
   git reflog
   

   You will see an output similar to this:

   TEXT
   a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~1
   e4f5g6h HEAD@{1}: commit: Add final project documentation
   i7j8k9l HEAD@{2}: checkout: moving from feature-branch to main
   

   Notice that e4f5g6h is the commit you "lost."

3. The Restoration: You can now move your branch pointer back to that specific hash:

   Bash
   git reset --hard e4f5g6h
   

   Your files are back in your working directory, and your commit is restored.

Hands-on Exercise

To practice this, simulate a recovery in your local repository:

1. Create a new file, add it, and commit it with a message like "Temporary test commit."
2. Run git reset --hard HEAD~1 to "delete" it.
3. Run git reflog to find the hash of that "Temporary test commit."
4. Use git reset --hard <hash> to bring it back.

Common Pitfalls

• Reliance on the Reflog: The reflog is local to your machine. If you work on multiple computers, the reflog on your laptop will not contain actions you performed on your desktop.
• Garbage Collection: Git periodically runs git gc to clean up dangling objects. While this rarely happens immediately, do not assume a deleted commit will stay in your local database forever.
• Misinterpreting the Reflog: The reflog shows where HEAD was. If you are confused, look for the timestamp or the commit message associated with the entry to ensure you are picking the right state to restore.

FAQ

Q: Does git reflog show commits pushed to GitHub? A: The reflog only tracks your local HEAD movements. It is a local safety tool, not a synchronization tool.

Q: What happens if I can't find the commit in the reflog? A: If the commit was never part of your local history (e.g., you created it on a different machine), the reflog cannot help. You would then need to look for git fsck --lost-found to find dangling objects, which is a much more advanced recovery process.

Q: Is it safe to use git reset --hard? A: It is "safe" only because you have the reflog. Always remember that reset --hard discards uncommitted changes, so check your git status first!

Recap

You now have the ability to recover from common mistakes using git reflog. By understanding that Git keeps a history of your local movements, you can confidently explore, navigate, and even "delete" commits knowing you have a path back to a known good state.

Up next: We will look at Advanced Branching Patterns, where we cover release branches and hotfix workflows to keep your production code stable.