Reflog와 Stash로 작업 복구하기

It feels like a bad reset or rebase destroys work, but Git almost never truly loses commits. They become unreachable, not deleted, and remain recoverable for weeks.

The reflog is your map back to them.

The reflog logs every move of HEAD and branch tips: commits, checkouts, resets, rebases, merges. It is local and not shared, a private diary of where your refs have been.

Ran git reset --hard and lost commits? Find the pre-reset SHA in the reflog and reset back to it.

A rebase rewrites commits. If it went wrong, the reflog still holds the pre-rebase tip. Point your branch back at it.

You do not always want to reset the whole branch. To resurrect just one commit, cherry-pick its SHA from the reflog.

Before risky recovery operations, save uncommitted work with git stash. It tucks changes away cleanly so you can experiment without losing them.

List stashes and bring one back. apply keeps it in the list; pop restores and removes it.

Dropped a stash by mistake? Stashes are commits too. Find the dangling commit and re-apply it.

When even the reflog does not show it, git fsck --lost-found hunts for dangling commits and blobs, the last-resort recovery tool.

Unreachable objects survive until garbage collection prunes them, by default after about 30 days for reflog entries. Recover promptly; do not let weeks pass before you go looking.

Remember: the reflog lives only in your clone. A teammate's reflog will not show your moves, and a fresh clone has none. If you need shared recoverability, push branches or tags before risky operations.

Test your understanding of Git recovery tools.

You learned Git's safety nets: the reflog recovers from bad resets and rebases, cherry-pick restores single lost commits, the stash protects work-in-progress, fsck hunts dangling objects, and the GC clock means you should recover promptly. Git rarely loses data if you know where to look.