How to undo and recover almost anything in Git

Stop and run git status and git reflog before trying anything else. Status usually names the command that fixes your situation, and the reflog records where you were before the mistake. Most damage happens after the original error, when people start running recovery commands they don't fully understand.

Only if it was staged with git add at some point — staging writes the content into Git's object database, where git fsck --lost-found can still find it. Content that was never staged and never committed was never given to Git, so no Git command can produce it. Your editor's local history is the realistic fallback.

Reflog entries survive 90 days for reachable commits and 30 for unreachable ones, after which garbage collection can remove the objects. That's a generous window, but act sooner rather than later — and never run git gc --prune=now while you're still trying to recover something.

Each guide states whether its fix rewrites history. Anything involving reset, rebase, amend, filter-repo or a force-push changes commits others may already have pulled, so on a shared branch prefer the revert-based alternative each guide offers. On your own branch, rewriting is normal and fine.

It's an honest estimate before you start. 'Always fixable' means Git has everything it needs. 'Usually recoverable' means it works if you act before garbage collection. 'Sometimes' depends on whether the content ever reached the object database, and 'rarely' means Git probably never saw it and the fix lies outside Git.

Yes — Git itself is identical on every platform. Where a step uses shell-specific syntax such as a loop or a pipeline, the guide includes a PowerShell version alongside the bash one, so you can copy whichever matches your terminal.

Paste the distinctive part of it into the search box above. Every guide lists the literal text Git prints, so searching 'dubious ownership', 'src refspec', 'MERGE_HEAD' or 'smudge filter' lands directly on the page that explains it rather than on something merely related.

Several of the most alarming ones are Git protecting you. A rejected push means the remote has commits you don't, 'refusing to merge unrelated histories' means the branches share no ancestor, and 'MERGE_HEAD exists' means an earlier operation is still open. In each case Git stopped precisely so nothing was lost.

No. Each guide gives the one command that fixes the common case first, then the full walkthrough for when it doesn't, and explains the mental model afterwards. Copy the quick fix if you're mid-crisis and come back for the reasoning when things are calm.