Recap — Why You Almost Never Lose Work

# Why You Almost Never Lose Work The reflog is one of Git's best features. It records every change to HEAD — every commit, checkout, reset, rebase. Even when commands seem destructive, reflog can usually recover. ## What's the reflog ```bash git reflog # abc123 HEAD@{0}: commit: Add feature # def456 HEAD@{1}: checkout: moving from main to feature # 7890ab HEAD@{2}: pull: Fast-forward # 4567cd HEAD@{3}: commit: Update README # ... ``` Each entry: SHA + operation + brief description. Newest at top. `HEAD@{N}` is shorthand: N commits/operations ago. ## When reflog saves you ### Lost a commit via reset --hard ```bash git reset --hard HEAD~1 # "oh no, I needed those changes" git reflog # find the lost commit git reset --hard abc123 # restore to it ``` ### Botched a rebase ```bash git rebase -i main # rebase goes wrong; commits scrambled git reflog # see the pre-rebase HEAD git reset --hard HEAD@{5} # back to before the rebase ``` ### Deleted a branch with unmerged commits ```bash git branch -D feature # deleted the branch # But! Commits are still in reflog. git reflog # find them git branch feature abc123 # recreate branch at the right commit ``` ### Force-pushed and lost remote commits If remote had commits you didn't and you force-pushed: - Your LOCAL reflog won't have them (you never had them locally). - A collaborator's reflog WILL have them (they may still have the SHAs). - The remote's history is gone (force-push overwrote). Recovery: ask a collaborator for the missing SHAs; push them back. ## What reflog doesn't save ### Uncommitted changes (working tree) If you `git reset --hard` while having uncommitted work in the working tree, those changes are GONE. Reflog only tracks commits, not unsaved edits. Lesson: commit or stash before destructive operations. ### Untracked files Files you never `git add`ed aren't anywhere in Git. `git clean -fd` deletes them; reflog can't recover. ### After garbage collection Reflog entries expire (default ~90 days). After expiration, Git can garbage-collect "unreachable" commits (those not referenced by any branch or tag, and not in active reflog). In practice: 90 days is plenty. If you're recovering ancient lost work, may be too late. ## Specific recovery patterns ### Recover from `git reset --hard` ```bash git reflog # 5678cd HEAD@{0}: reset: moving to HEAD~1 # abc123 HEAD@{1}: commit: My lost work # ... git reset --hard abc123 # back to before the reset ``` ### Recover from interactive rebase gone wrong ```bash git reflog # Look for: HEAD@{N}: rebase: ... (the rebase entries) # Look for: HEAD@{N+1}: rebase (start): checkout ... # The commit right before is your pre-rebase state. git reset --hard HEAD@{N+1} ``` ### Recover a deleted branch ```bash git reflog # find a commit that was on the deleted branch git branch recovered abc123 # create a branch at that commit git switch recovered ``` If you don't have the SHA but know the branch name was "feature": ```bash git reflog --all | grep feature # search reflog ``` ### Recover after `git commit --amend` Amend creates a new commit; the old SHA is in reflog. ```bash git reflog # Find the pre-amend commit's SHA git reset --hard ``` ## Reflog per-branch Each branch also has its own reflog: ```bash git reflog feature # reflog for the `feature` branch git reflog main ``` Useful when you reset a branch and want to find prior states. ## Reflog vs log - `git log` shows the current branch's history (reachable from HEAD). - `git reflog` shows EVERY position HEAD has been, regardless of branch. Reset moves HEAD; old commits become unreachable from any branch but ARE in reflog. ## Expiration and gc ```bash git config gc.reflogExpire 90.days # default: 90 days git config gc.reflogExpireUnreachable 30.days # for unreachable commits in reflog ``` Manual gc: ```bash git gc # cleanup; safe git gc --aggressive # more thorough; slower git gc --prune=now # prune unreachable immediately (destructive!) ``` For safety, don't `--prune=now` unless you really want unreachable commits gone. ## fsck — find lost commits If reflog has expired but commits might still exist: ```bash git fsck --lost-found # Checking object directories: 100% (256/256), done. # dangling commit abc123... ← orphan commits not in any branch or reflog ``` Once found, you can `git show abc123` and recover. This is the last-resort recovery. ## Best practices 1. **Commit often** (even WIP commits) — gives reflog entries to recover from. 2. **Stash before destructive operations** — explicit save. 3. **Avoid `--prune=now`** unless intentional. 4. **Push regularly** — remotes are independent of your reflog. ## Common reflog mistakes 1. **Believing `git reset --hard` is final.** Reflog can usually recover. 2. **Not committing before risky opera