How to Recover a Deleted Branch in Git: A Step-by-Step Guide for Developers

Learn how to recover a deleted Git branch with this step-by-step guide. Explore beginner, intermediate, and advanced techniques using Git reflog and commit history, along with best practices for preventing accidental branch deletion.

You ran git branch -D on the wrong branch, hit enter, and your stomach dropped. That branch had a day of unpushed work on it. We’ve all done it, and here’s the good news: you almost certainly haven’t lost a thing.

Git rarely throws work away the moment you delete a branch. Deleting a branch removes a label, not the commits behind it. Those commits sit in your repository for a while before Git cleans them up, and there’s a paper trail to find them again. Let’s walk through how to get your branch back, from the fast case to the ugly one.

Table of Contents

• Introduction to Git Branches
• Basic Branch Recovery Techniques
• Intermediate Branch Recovery: Git Reflog
• Advanced Branch Recovery Techniques
• Preventing Accidental Branch Deletion
• Conclusion

Introduction to Git Branches

A branch in Git is just a movable pointer to a commit. When you create a branch, you’re not copying your files. You’re writing down one commit hash and giving it a name. That’s why branches are cheap to make and cheap to delete.

It also explains why deletion is recoverable. When you delete a branch, Git erases the name, but the commit it pointed to is still there. That commit only truly disappears later, when Git runs garbage collection and decides nothing references it anymore. Until then, you can point a new name back at it.

Creating and Deleting Branches

Here’s the basic lifecycle of a branch:

# Create a new branch
git branch new-feature
# Switch to the new branch
git checkout new-feature
# Delete a branch
git branch -d new-feature

Two things are worth knowing about that last command. git branch -d is the safe version: Git refuses to delete a branch that holds commits you haven’t merged anywhere, so it catches most accidents for you. git branch -D is the force version, and it deletes no matter what. Either way, watch the output. Git prints the commit hash it just orphaned, something like Deleted branch new-feature (was f7e1c23). That hash is your fastest ticket back, so copy it before it scrolls off screen.

Basic Branch Recovery Techniques

If you deleted the branch a moment ago and still have the terminal open, recovery is a one-liner. All you need is the commit hash the branch was pointing at.

Using the Commit History

If the deleted branch was already merged into the branch you’re on, its commits still live in your normal history, and you can pull the hash straight from there:

# List all commits to find the one you're looking for
git log --oneline
# Once you find the commit hash, create a new branch from that commit
git checkout -b recovered-branch <commit-hash>

That rebuilds the branch from the commit you name. One honest caveat: git log only walks commits reachable from where you are right now. If the branch you deleted had work that was never merged, those commits won’t show up here at all. That’s the usual panic case, and it’s exactly what the reflog is for.

Recovering a Recently Deleted Branch

When the lost work never got merged, don’t waste time scrolling git log. Reach for the reflog, which remembers where you’ve been even when nothing else does.

Intermediate Branch Recovery: Git Reflog

The reflog is Git’s memory of every place your HEAD has been: every checkout, commit, reset, and merge. Deleting a branch doesn’t wipe that trail, so the reflog usually still knows the commit your branch was sitting on right before it vanished.

Using Git Reflog

Here’s the recovery:

# View the reflog
git reflog
# Look for the entry where the branch was deleted
# Example: f7e1c23 HEAD@{0}: checkout: moving from deleted-branch to main
# Recover the branch by checking out the commit
git checkout -b recovered-branch f7e1c23

Read the reflog top to bottom and find the moment just before the delete, often the checkout line that moves you off the branch. In this example f7e1c23 is the commit the branch last pointed to, and git checkout -b pins a fresh branch right back onto it.

A word on timing. Reflog entries don’t live forever. By default Git keeps them about 90 days, but only 30 days for entries whose commit is no longer reachable, which is exactly the situation after a delete. So you have weeks, not minutes, but don’t sit on it for a month.

Listing All Deleted Branches

Not sure which branch you nuked, or what it was even called? Scroll the reflog and look for checkout entries naming a branch you don’t recognize anymore. Once you spot the commit it sat on, recover it with the same git checkout -b command above.

Advanced Branch Recovery Techniques

Sometimes the easy paths run out. Maybe you deleted the branch weeks ago, ran a pile of Git operations since, or the reflog entry already expired. The commit can still be sitting in your object store, just floating with no name pointing to it. Git calls these dangling commits.

Recovering Branches After Garbage Collection

Garbage collection is the cleanup pass that eventually removes unreferenced objects. It kicks off on its own from time to time, but there’s a grace period first (two weeks by default) before an unreachable commit actually gets pruned. Until that happens, you can still dig the commit out with Git’s lower-level tools:

# List all dangling commits
git fsck --lost-found
# You can then inspect these commits and recover the branch if needed
git show <dangling-commit>

git fsck --lost-found reports every dangling commit it can find and writes them somewhere you can inspect. Run git show on each hash until you recognize your work, then rebuild the branch from it with the same git checkout -b pattern from the reflog section.

Fair warning: on a busy repo this is a needle in a haystack, and once garbage collection has genuinely pruned the commit, it’s gone. Treat this as the last resort, not the plan.

Force-Deleting a Branch and Recovering It

A branch killed with git branch -D comes back the same way as any other: reflog first, dangling commits second. Force delete doesn’t shred the commits any harder, it just skips the safety check. Still, only reach for -D when you’re sure, because it removes the one guardrail Git hands you.

Preventing Accidental Branch Deletion

Recovery is nice. Not needing it is nicer. A few habits keep branches off the chopping block:

• Push work in progress. A branch that also lives on a remote, or is protected there, survives any local slip.
• Read before you delete. Run git branch to confirm the exact name, and prefer git branch -d so Git can stop you from dropping unmerged work.
• Keep real work on feature branches, not on main, so a stray delete can’t take your trunk down with it.

None of this is heavy lifting. It’s the difference between a shrug and a scramble.

Conclusion

Deleting a branch feels final, but it rarely is. The name goes; the commits stick around. Check the delete message for the hash, lean on the reflog when the work was never merged, and fall back to dangling commits if you’ve waited too long. Nine times out of ten you’re back to work in under a minute.

Build the small habits above and this stops being a scare at all. And the next time a teammate goes pale over a deleted branch, you’ll be the one who fixes it in one command.