Disaster Recovery: Recovering Lost Commits & Fixing Real Mistakes

In one line

A calm, systematic checklist for the genuinely scary Git moments — a deleted branch, a bad force-push, a corrupted-looking repository — built entirely from tools this course has already covered.

0/5 · 0%

Think of it like this

A fire evacuation plan posted on a wall — genuinely useful specifically BECAUSE it was written and read calmly, in advance, rather than being figured out for the first time during the actual emergency. This topic is exactly that plan for Git's scariest, most common real disasters.

Key ideas

01
DISASTER 1 — 'I deleted a branch with unmerged work': git reflog (Phase 5.3) almost always still shows the deleted branch's last commit — git branch <new-name> <that-sha> recreates it instantly. This works because deleting a branch only removes the POINTER, not the underlying commit objects, which remain intact until actual garbage collection, well after the reflog's default retention window.
02
DISASTER 2 — 'someone force-pushed and my commits vanished from the shared branch': check YOUR OWN local reflog first (git reflog on your machine still remembers where the branch was before you last fetched the bad force-push) — if you have the commits locally, git cherry-pick or git rebase them back onto the corrected branch; if genuinely nobody has them anymore, this is exactly why branch protection disabling force-push on shared branches (Phase 5.4) exists.
03
DISASTER 3 — 'a bad merge or rebase already got pushed': git revert -m 1 <merge-sha> (Phase 4.3) safely undoes a bad merge without rewriting shared history; for a bad rebase already pushed and pulled by others, the cleanest fix is often coordinating with the team to reset everyone's local copies to a known-good point, since the golden rule against rewriting shared history applies with full force here.
04
DISASTER 4 — 'my working directory changes are gone and I never committed them': this is the one genuine limitation of Git's safety net (Phase 5.3) — uncommitted changes have no reflog entry and no recovery path through Git itself, though some editors keep their own local history/backup independent of Git that's worth checking. This is exactly why committing early and often, even to a disposable branch, is cheap, real insurance against this specific failure mode.
05
The universal first response to ANY Git disaster, before touching anything else: STOP, take a breath, and run git status and git reflog before making any further changes — most 'catastrophic' Git situations are fully recoverable using tools this course has already covered, and panicked, hasty additional commands are far more likely to make a recoverable situation genuinely worse than the original mistake was.

Code & diagrams

disaster-recovery-checklist.shmarkdown

The complete triage sequence — always start here before anything else.

# STEP 1 — ALWAYS start here, before touching anything else
git status
git reflog

# --- Disaster: deleted a branch with unmerged work ---
git reflog | grep "checkout: moving from <deleted-branch-name>"
# find the SHA it was at right before deletion, then:
git branch recovered-branch <that-sha>

# --- Disaster: commits vanished from a shared branch after a bad force-push ---
# Check YOUR OWN reflog first — you may still have them locally
git reflog
git log --oneline <sha-from-reflog>
# if found, cherry-pick or reset the correct branch back onto them

# --- Disaster: a bad merge already pushed ---
git log --oneline --merges           # find the bad merge commit
git revert -m 1 <bad-merge-sha>      # safe — adds a new commit, rewrites nothing
git push

# --- Disaster: uncommitted changes are gone ---
# Git itself has no recovery path for this — check your EDITOR's own local
# history/backup feature first (many keep independent undo history);
# this is exactly why committing early, even to a throwaway branch, matters

# --- Genuinely unsure what state you're in? ---
git log --graph --oneline --all      # see the FULL picture across every branch
git fsck --lost-found                # find any genuinely orphaned, unreferenced commits

Explain it without notes

Why does deleting a Git branch not actually delete its commits immediately, and what does this mean for recovery?

Why is 'uncommitted, never-staged changes are permanently lost with no Git-based recovery' specifically true, when so much else in Git is recoverable?

Practice

Deliberately delete a branch with an unmerged commit, then use git reflog to find and recreate it under a new name.

Simulate the 'gone from the shared branch' scenario locally: reset a branch back a commit (simulating someone else's bad force-push overwriting your view of it), then recover the 'lost' commit using your own reflog.

Trade-offs

↔
Git's recovery mechanisms cover an impressively wide range of 'disasters' — but they all fundamentally depend on the mistake being about COMMITTED work; the one genuine gap (uncommitted, never-staged changes) is entirely within your own control to close, simply by committing more frequently, even to a disposable branch nobody else needs to see, specifically so more of your work always has a real recovery path if something goes wrong.

Done when you can

I have a calm, systematic first response (status, reflog) for any Git disaster, rather than panicking.
I can recover a deleted branch and 'lost' commits using the reflog.
I understand the one genuine gap in Git's recovery model: uncommitted, never-staged changes.