Recover a deleted Git branch
Find a surviving branch tip in local refs, the reflog, or remaining objects, then recreate the branch. Recovery depends on object availability, not a fixed deadline.
You can recreate a deleted branch if its tip commit still exists in a repository you can access. Deleting the branch removes a reference; it does not immediately erase every commit that reference reached. Preserve a surviving reference as soon as you find it.
Find and restore the local branch tip
Start with the local HEAD reflog:
git reflog
Look for the last commit made on the branch or an entry showing its checkout history. The deleted branch’s own reflog is removed when that branch is deleted, but the HEAD reflog or another reference may still identify its tip.
Inspect a candidate before restoring it. Replace a1b2c3d with the actual hash:
git show --stat a1b2c3d
git log --oneline a1b2c3d -5
git branch feature-x a1b2c3d
This restores the branch without switching your working tree. When ready, use git switch feature-x. To create and switch in one step instead, use git switch -c feature-x a1b2c3d or the older git checkout -b equivalent.
If no useful reflog entry remains, search for objects that are no longer reachable through refs:
git fsck --no-reflogs --unreachable
Inspect candidate unreachable commit hashes with git show and git log, then create a branch at the correct tip. This search can also show older ancestors, not just the tip you need. Unlike git fsck --lost-found, it does not write recovered objects into a lost-found directory.
Restore a remote branch
If a local feature-x still contains the intended history, publish it again and configure its upstream:
git push -u origin feature-x
Check the destination and current remote state first. If someone recreated the branch with different work, investigate a rejected push rather than forcing over it.
A collaborator may still have the deleted branch or a stale remote-tracking reference. Preserve that reference before pruning it:
git branch recovered-feature origin/feature-x
After verifying the recovered history, it can be pushed back under the original name:
git push origin recovered-feature:refs/heads/feature-x
Hosting platforms may offer their own restoration UI. GitHub documents a Restore branch action on closed pull requests; availability depends on the pull request and your permissions. Do not assume every host or deletion path provides the same recovery option.
Reduce the chance of losing the last reference
Before deleting an important branch, you can keep a tag at its tip:
git tag archive/feature-x feature-x
Push the tag to an appropriate remote if it needs to survive loss of the local repository. Branch deletion does not delete the tag. Follow the team’s branch-deletion process, but do not treat a hosting UI’s restore button as a backup plan.
Frequently asked questions
How long is recovery possible?
There is no guaranteed window. Common reflog defaults are 90 days for ordinary entries and 30 days for entries unreachable from the current tip, but configuration, expiry, object pruning, and other references all affect availability. Avoid cleanup operations while investigating and create a retaining reference promptly.
Does recreating a branch restore its upstream?
Creating it from a raw commit hash does not restore its old tracking configuration. Use git push -u when publishing it, or git branch --set-upstream-to=origin/feature-x feature-x if the correct remote-tracking branch already exists.
What if garbage collection already ran?
Running garbage collection does not necessarily mean the commit was deleted. Check whether the object still exists. If it has been pruned from this repository, recovery requires another clone, a remote that retained it, or a backup.
References
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan