How to recover a dropped Git stash, a deleted branch or lost commits

When you drop a stash or delete a branch, Git removes the name, not the commits. The commits stay in the repository as unreachable objects until garbage collection prunes them, usually after two weeks or more. Find a deleted branch’s last commit in the reflog with git reflog, find a dropped stash with git fsck --unreachable, check it with git show, then keep it with git branch rescue <sha>.

This guide covers each case with the exact commands, explains how long Git keeps lost work and what cannot be recovered, and shows the same recovery in GitTree’s Lost & Found, which searches every source at once and never checks out or resets anything. Lost & Found is part of GitTree’s Free plan. To undo a reset, a rebase or an amend, read how to undo git reset, rebase and commit instead.

Where “lost” Git work actually lives

A commit is reachable when a branch, a tag, the stash or HEAD leads to it. Deleting a branch or dropping a stash makes its commits unreachable, but they remain in .git/objects. Two records help you find them: the reflog, where each branch and HEAD pointed before, and the object database itself, which git fsck can search.

Recover a deleted branch

Git prints the branch’s last commit when you delete it (Deleted branch feature/login (was 3f2a9c1)). If that message is gone, search HEAD’s reflog for the last time you were on the branch, then recreate the branch at that commit.

# find the last commit of the branch
git reflog | grep "feature/login"

# check what it holds
git show 3f2a9c1 --stat

# put the branch back
git branch feature/login 3f2a9c1

Recover a dropped stash

A stash has no reflog of its own once it is dropped, so search the unreachable commits. A stash is a merge-shaped commit whose message starts with WIP on or On <branch>:, which makes it easy to filter. This is the method Git’s own stash documentation describes.

# list unreachable stash-like commits, newest first
git fsck --unreachable | grep commit | cut -d" " -f3 \
  | xargs git log --merges --no-walk --grep=WIP --format="%h %cr %s"

# inspect a candidate
git stash show -p 7c1e0b4

# restore it into your working tree, or keep it on a branch
git stash apply 7c1e0b4
git branch rescue-stash 7c1e0b4

Find every dangling commit with git fsck --lost-found

git fsck --lost-found lists the dangling commits and writes a copy of each into .git/lost-found/commit/, named by its id. Use it when you do not know what you are looking for: list them with their dates and messages, then branch from the one you want.

git fsck --lost-found
ls .git/lost-found/commit | xargs git log --no-walk --format="%h %cr %s"
git branch rescue 9d44b0e

How long Git keeps lost commits

Garbage collection runs on its own after some commands, so these are windows, not promises. The sooner you look, the more you find. A copy elsewhere, such as a teammate’s clone or a pushed branch, is the other safety net: lost work only on your computer exists only there.

What cannot be recovered

• Changes that were never committed or stashed, such as edits thrown away with git checkout -- <file> or git restore.
• Untracked files that were not in a stash made with -u.
• Commits that garbage collection has already pruned.
• Work that only ever existed on another person’s computer.

Next steps: the Lost & Found guide documents every page and button, find previous branch tips covers the reflog view, and the git stash guide explains apply, pop and untracked files so you need recovery less often.