CHAPTER 09
Recovering from Git Mistakes
Updated: May 15, 2026
25 min read
# CHAPTER 9
Recovering from Git Mistakes
1. Introduction
The true power of Git is not collaboration; it is invincibility. Git is a highly resilient time machine. It is almost mathematically impossible to permanently delete code in Git unless you explicitly force the system to delete the backups. If you resolve a merge conflict incorrectly and accidentally delete production code, or if you merge a completely broken branch intomain, you do not need to panic. In this chapter, we will master the emergency recovery protocols. We will learn how to safely undo merges, differentiate between reset and revert, and utilize the ultimate safety net: the git reflog.
2. Learning Objectives
By the end of this chapter, you will be able to:- Undo an uncommitted, botched merge attempt.
-
Understand the dangers of rewriting public history with
git reset.
-
Use
git revertto safely undo a public merge commit.
- Define what the Git Reflog is and why it is a lifesaver.
- Recover accidentally deleted branches and commits using the reflog.
3. Beginner Explanation
Imagine you are typing a crucial document.- The Mistake: You accidentally highlight the entire document and hit the "Delete" key. The text is gone.
-
The Soft Fix (
Ctrl+Z): You haven't saved and closed the file yet. You just hitCtrl+Z(Undo), and the text comes back. In Git, this isgit merge --abort.
-
The Hard Fix (Revert): You saved the document, printed it, and mailed it to the boss. You can't use
Ctrl+Zanymore because the boss already has it! You have to type a completely new letter saying: "Please ignore my last letter, here is the corrected text." In Git, this isgit revert.
-
The Ultimate Backup (Reflog): You threw your computer out the window. But wait! Your computer automatically takes a hidden photograph of your screen every 5 seconds. You buy a new computer, look at the photograph, and type the text back out. In Git, this hidden photographic memory is the
reflog.
4. Undoing an Uncommitted Merge
If you typegit merge feature and get a massive conflict, and you realize you have no idea what you are doing, do not start deleting code. You haven't committed the merge yet.
Simply run:
bash
This instantly cancels the merge state and restores your files to how they looked before the merge began.
5. Reverting a Completed Public Merge
The catastrophe: You resolved the conflicts, committed the merge, pushed it to GitHub, and the live production website crashed. You cannot just delete the commit, because your coworkers already downloaded it. You must create a *new* commit that perfectly reverses the damage.
bash
Git will create a new commit titled "Revert...". Push this to GitHub, and the website is instantly fixed. Your coworkers pull the new commit, and everyone remains synchronized.
6. The Ultimate Lifesaver: The Git Reflog
You committed a fix, but you typedgit reset --hard by accident and completely wiped out your last three days of work. It doesn't show up in git log. It seems gone forever.
It is not gone.
Git secretly records every single time the tip of a branch moves, even if you delete the branch or reset the history. This hidden ledger is the Reference Log (Reflog).
bash
The output will look like this:
text
Even though the database patch was deleted from the official history, its hash (f9e8d7c) is still sitting in the reflog.
7. Mini Project: Recover Broken Git History
Let's simulate a catastrophe and recover it using the reflog.Step-by-Step Walkthrough:
-
1.
In a practice repository, create a file and commit it:
echo "Important Code" > app.js && git add . && git commit -m "Important"
- 2. The Catastrophe: You accidentally run a hard reset, wiping the commit from existence:
bash
git reset --hard HEAD~1
`
-
3.
Run
git log. The "Important" commit is gone. The file is missing from your folder. Panic sets in.
-
4.
The Recovery: Run
git reflog.
-
5.
Look at the top of the list. You will see the hash of your "Important" commit right before the reset action. Copy that hash (e.g.,
a1b2c3d).
-
6.
Force Git to travel back in time to that specific hash:
`bash
git reset --hard a1b2c3d
`
-
7.
Run
git log. The commit is back! Open your folder. app.js is back! You just resurrected dead code.
8. Best Practices
-
Do Not Rely on Reflog Forever: The reflog is an emergency net, not permanent storage. By default, Git automatically runs garbage collection and permanently deletes unreferenced commits from the reflog after 30 to 90 days. If you lose code, recover it immediately.
9. Common Mistakes
-
Using
git reset --hard on Public Branches: git reset erases history. If you erase a commit that is already on GitHub, and then force-push your erased history, you will break the repository for every other developer. Never use reset to undo public mistakes; always use git revert.
10. Exercises
-
1.
What is the fundamental difference in the methodology of undoing a mistake using
git revert versus git reset?
-
2.
Explain what the
git reflog tracks and why it is capable of recovering commits that git log cannot see.
11. FAQs
Q: Does GitHub or GitLab have a reflog?
A: The reflog is entirely local to your specific laptop. It tracks what *your* computer did. GitHub does not have a public reflog. If you delete a local commit and never pushed it, only your local reflog can save you.
12. Summary
In Chapter 9, we conquered the fear of making catastrophic mistakes. We learned that Git defaults to immense safety, providing multiple avenues for time travel and recovery. We distinguished between the surgical precision of aborting an uncommitted merge, the safe public undoing provided by git revert, and the absolute historical erasure of git reset. Finally, we unlocked Git's ultimate hidden superpower: the reflog`, ensuring that no localized mistake is ever truly fatal.