lost git work, one lesson per page
Thirty lessons for recovering lost Git work: the reflog as the map of where HEAD has been, dangling commits and why deleted work still exists locally, git fsck and --lost-found, recovery after a reset --hard, a failed rebase, a deleted branch and a detached HEAD, cherry-picking work back instead of resetting, the stash and dropped stashes, and the expiry windows that decide how long the safety net holds.
A diagram, the recovery, and one thing to try this week. That's a page.
lost git work, one lesson per page
Thirty lessons for recovering lost Git work: the reflog as the map of where HEAD has been, dangling commits and why deleted work still exists locally, git fsck and --lost-found, recovery after a reset --hard, a failed rebase, a deleted branch and a detached HEAD, cherry-picking work back instead of resetting, the stash and dropped stashes, and the expiry windows that decide how long the safety net holds.
Set in Space Grotesk, Inter and JetBrains Mono (SIL Open Font License).
Every fact in this book is as the official source states it, fetched and read during this build: the git-reflog, git-fsck, git-reset, git-rebase, git-stash, git-gc, git-cherry-pick and gitglossary pages at git-scm.com/docs, the Maintenance and Data Recovery chapter of Pro Git at git-scm.com, the local git man pages shipped on the build server, and live observed output from a scratch repository built for this book, git 2.43.0; expiry defaults are stated as the git-gc documentation states them. Demand evidence from live developer threads, reconfirmed at dispatch; no facts are sourced from Reddit, Stack Overflow or tutorials. An independent guide, not affiliated with or endorsed by the Git project.
Your purchase is for personal use only. You do not have redistribution rights: please do not share, resell, or republish this book or its pages.
© 2026 Steve Hodgkiss. All rights reserved. Personal use only; no redistribution rights.
Edition 1.0 · stevehodgkiss.net
Contents
Per the Pro Git chapter Maintenance and Data Recovery: "Each time you commit or change branches, the reflog is updated."
HEAD keeps a diary
Panic says the work is gone. The diary says otherwise: every move of HEAD is logged. Per the Pro Git chapter on recovery, each time you commit or change branches, the reflog is updated.
That includes the moves you regret. The reset, the rebase, the checkout: each one leaves a line naming where HEAD used to point.
Recovery in git starts by reading, not by undoing.
Run git reflog in any repository this week and read the last five lines: name the move each one records.
Observed live: git fsck printed "dangling commit 7eeaee7..." for a commit orphaned by a reset; per gitglossary(7), a dangling object is unreachable even from other unreachable objects.
Dangling commits
fsck's word for the deepest orphan is dangling: per the glossary, an object unreachable even from other unreachable objects, with nothing pointing at it anywhere.
Observed live, one run printed three dangling commits: a rebased-away feature, a dropped stash, a hard-reset commit, each still recoverable by sha.
A dangling commit is a lost tip with its sha printed next to the word dangling.
Run git fsck in a repository you have rebased this week; read every dangling line it prints.
Observed live: after that reset, git branch recovered HEAD@{1} restored the full log with 7eeaee7 fourth commit on top; per the Pro Git recovery chapter, "you can recover it by creating a new branch at that commit".
Undo a hard reset
The undo is not another reset. Read the reflog, find the commit before the move, and put a new branch label on it.
Observed live, git branch recovered HEAD@{1} brought back the whole lost history, fourth commit first, exactly as Pro Git describes: recover by creating a new branch at that commit.
Reset again and you risk a second mistake; branch, and you risk nothing.
Complete the scratch drill this week: lose a commit to reset --hard, rescue it with git branch recovered HEAD@{1}.
Observed live: the reflog line "4f02b11 HEAD@{5}: commit: feature work" named the deleted branch's tip, and git branch feature 4f02b11 restored its log. Per Pro Git: start a branch at the commit the reflog names.
Recover the branch
The branch is gone; the diary that watched it is not. Scan the HEAD reflog for the tip, then re-point a name at that sha.
Observed live, one reflog line named the deleted tip, and git branch feature 4f02b11 put the whole branch back.
Pro Git's worked example is this exact move: a new branch at the commit the reflog names.
Memorise the pattern this week: git reflog to find the sha, git branch with name and sha to claim it.
Observed live: git stash drop printed "Dropped stash@{0} (7b6fb6e...)" and git fsck then listed that sha as a dangling commit; per git-stash(1), dropped entries "cannot be recovered through the normal safety mechanisms" but can be found with fsck --unreachable.
A dropped stash lives
Dropping a stash is deleting a label, again. Observed live, the command printed the sha as it let go: Dropped stash@{0} (7b6fb6e...).
The manual is blunt that the normal mechanisms will not list it any more, and offers the fallback: find the dangling commit with fsck, then branch at it.
A dropped stash is a commit nobody names; name it and it is a branch.
If you drop a stash this week, copy the sha from the drop line before the terminal closes.
This book's plan, assembled from git-reflog(1), git-fsck(1) and Pro Git: the diary, the checker, the new name.
One habit to keep
When work goes missing, the ladder is short: git reflog for the diary, git fsck, with --lost-found to file the finds, then a branch at the sha to make it reachable.
Underneath the ladder sit the two habits that empty it: branch first, commit before surgery.
You will lose work again. Now you know it is almost always still there.
Keep the ladder visible this week, and run one full rescue drill in a scratch repository.