By Kedar Salunkhe | Last Updated March 2026
You deleted a branch.
Maybe you thought the work was merged. Maybe you accidentally clicked “Delete branch” on GitHub after a pull request closed. Maybe you ran git branch -d feature/signup and then immediately realized the merged work was missing two important files. Maybe you ran git branch -D — the force delete — and felt the blood drain from your face as you hit Enter.
Whatever happened, the branch is gone. And now the question is: is the work gone too?
Here’s the answer most people don’t know: almost certainly not.
This is one of the most common Git panics, and it’s almost always recoverable. Git doesn’t actually delete commit data when you delete a branch. A branch in Git is just a pointer — a lightweight label that points to a specific commit. When you delete the branch, you delete the label. The commits that the branch was pointing to are still sitting in your repository, quietly waiting. They’re just temporarily unlabeled.
The git reflog is what saves you here. It’s Git’s internal diary — a record of every position your HEAD has been in, every branch you’ve checked out, every commit you’ve made. As long as the commits from your deleted branch are still in the reflog (which they will be for 30 to 90 days), you can bring them back.
This guide walks you through every recovery scenario, step by step, in plain language. Whether you deleted a branch locally, on GitHub, or both — whether you merged it first or didn’t — there’s a path back. Let’s find it.
How to Restore a Deleted Branch in Git (Beginner-Friendly Tutorial)
Before We Start — What Actually Happens When You Delete a Branch
Understanding this takes two minutes and makes the rest of the guide much clearer.
In Git, a branch is not a folder. It’s not a copy of your files. It’s not a container that holds commits.
A branch is a pointer. Specifically, it’s a file in your .git/refs/heads/ directory that contains a single commit hash. That’s the entire branch. When you’re on the main branch, the file at .git/refs/heads/main contains something like:
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
That hash points to the most recent commit on main. Every time you make a new commit, Git updates that file to point to the new commit. The new commit itself stores a reference to its parent commit. Follow the chain of parent references backwards and you have the full history of the branch.
So when you run git branch -d feature/login, Git does one thing: it deletes the file .git/refs/heads/feature/login. The commits that file was pointing to are not deleted. They’re still in the repository’s object database. They’re just not reachable by following any branch pointer anymore — they’re what Git calls “dangling” or “unreachable” commits.
Git runs a garbage collection process (git gc) periodically to clean up unreachable objects. But this doesn’t happen immediately. By default, unreachable commits are kept for at least 30 days before garbage collection can remove them. The reflog provides an additional layer of protection — commits referenced in the reflog are protected from garbage collection for the full reflog retention period (90 days by default).
This is your recovery window. As long as you act before garbage collection removes the commits, your work is recoverable.
The practical takeaway: deleting a branch in Git is almost never permanent. Especially if you catch it quickly.
Method 1 — Restore From git reflog (Best Method for Local Deletions)
This is the most reliable method for recovering a branch that was deleted locally. The reflog records the history of where HEAD has been — including when you were on the branch you just deleted — and from there you can find the commit hash needed to recreate it.
Step 1 — Open the Reflog
git reflog
This outputs a list of recent HEAD positions. It looks like this:
a1b2c3d HEAD@{0}: checkout: moving from feature/login to main
e4f5g6h HEAD@{1}: commit: Add password hashing to login
b2c3d4e HEAD@{2}: commit: Implement login form validation
9i8j7k6 HEAD@{3}: commit: Start login feature
f5e4d3c HEAD@{4}: checkout: moving from main to feature/loginRead from the top. The most recent action is at the top. You can see the moment you moved from feature/login to main (HEAD@{0}). Just below it are the commits that were on feature/login before you deleted it.
Step 2 — Find the Last Commit on the Deleted Branch
Look through the reflog for the most recent commit that was on your deleted branch. In the example above, that’s HEAD@{1} — the “Add password hashing to login” commit — with hash e4f5g6h.
That hash is the tip of your deleted branch. It’s the last commit that was on feature/login before it was deleted.
If your reflog is long and the branch is hard to find, use grep to filter:
git reflog | grep feature/login
This narrows the output to only lines mentioning your branch.
Step 3 — Recreate the Branch From That Commit
git checkout -b feature/login e4f5g6h
This creates a new branch named feature/login starting at commit e4f5g6h. It’s an exact recreation of your deleted branch at its last known state.
Alternatively, if you want to recreate the branch but stay on your current branch (without checking it out):
git branch feature/login e4f5g6h
Step 4 — Verify the Recovery
git log –oneline feature/login
This shows the commit history of the recovered branch. Confirm all your commits are there.
git checkout feature/login
git status
Make sure your files are as expected.
Full Example
$ git branch
- main
feature/login
feature/signup
$ git branch -d feature/login
Deleted branch feature/login (was e4f5g6h).
[Oh no. That branch wasn't fully merged. Need it back.]
$ git reflog
a1b2c3d HEAD@{0}: checkout: moving from feature/login to main
e4f5g6h HEAD@{1}: commit: Add password hashing to login
b2c3d4e HEAD@{2}: commit: Implement login form validation
9i8j7k6 HEAD@{3}: commit: Start login feature
$ git checkout -b feature/login e4f5g6h
Switched to a new branch 'feature/login'
$ git log --oneline
e4f5g6h (HEAD -> feature/login) Add password hashing to login
b2c3d4e Implement login form validation
9i8j7k6 Start login feature
f5e4d3c Initial commit[All commits recovered. Branch fully restored.]
A Shortcut When Git Tells You the Hash
When you delete a branch with git branch -d or git branch -D, Git actually prints the hash of the last commit in the output:
Deleted branch feature/login (was e4f5g6h).If you just ran that command and are looking at that output right now, you don’t even need the reflog. Just use the hash Git printed:
git checkout -b feature/login e4f5g6h
Done. Branch restored in one command.
Method 2 — Restore From GitHub (When the Branch Was Deleted on the Remote)
If the branch was deleted on GitHub — either through the GitHub interface, through the “Delete branch” button after merging a pull request, or by a teammate — and you still have the branch locally, recovering it is simple.
If you have the branch locally and just need to push it back up:
git push origin feature/login
That’s it. One command. The branch is restored on GitHub.
If You Don’t Have the Branch Locally Either
This is the more serious scenario — both the local and remote copies are gone. In this case, you need to recover the commits using Method 1 (git reflog), then push the recovered branch back to GitHub.
Step 1 — Recover the branch locally (using Method 1)
git reflog | grep feature/login
git checkout -b feature/login COMMIT-HASH
Step 2 — Push the recovered branch to GitHub
git push origin feature/login
GitHub will create the remote branch again pointing at the same commit.
The GitHub Interface Option — Restore Branch Button
GitHub has a built-in branch restoration feature that many developers don’t know about. After a pull request is merged and its branch is deleted, GitHub shows a “Restore branch” button on the pull request page for a limited time.
To find it:
Go to your repository on GitHub.
Click the Pull requests tab.
Click Closed to see closed pull requests.
Find the pull request that was associated with the deleted branch.
Scroll to the bottom of the PR. If the branch was deleted after the merge, you'll see a "Restore branch" button in gray.
Click it. GitHub recreates the branch pointing at the exact commit it was at when the PR was merged. No terminal commands needed.This works for branches deleted through GitHub’s interface. It may not work for branches deleted through the command line that were never pushed. And it only works within a certain window — GitHub doesn’t keep this option available indefinitely.
Checking if a Branch Still Exists on the Remote
Before doing anything, it’s worth checking whether the branch still exists on GitHub even if it’s gone locally:
git fetch –all
git branch -r
The -r flag lists remote branches. If you see origin/feature/login in the list, the branch still exists on the remote. Restore it locally with:
git checkout feature/login
Or explicitly:
git checkout -b feature/login origin/feature/login
Git will set up the local branch tracking the remote one.
Method 3 — Restore Using git fsck (For Finding Lost Commits Without Reflog)
The reflog is the first tool to reach for, but there’s a secondary option for cases where the reflog doesn’t show what you need — perhaps because too much time has passed, or because you’re working on a machine where the reflog is minimal, or because you cloned a fresh copy of the repository and the reflog doesn’t have the branch history.
git fsck (filesystem check) scans the entire Git object database for dangling commits — commits that exist in the repository but aren’t reachable from any branch or tag. Your deleted branch’s commits are likely in this list.
Step 1 — Run git fsck
git fsck –lost-found
This outputs a list of unreachable objects. It looks something like this:
Checking object directories: 100%
dangling commit e4f5g6h…
dangling commit b2c3d4e…
dangling blob 9i8j7k6…
dangling tree f5e4d3c…The “dangling commit” lines are what you’re interested in. Each one is a commit that exists in the repository but isn’t attached to any branch.
Step 2 — Inspect Each Dangling Commit
For each dangling commit hash, inspect it to figure out which one is the tip of your deleted branch:
git show e4f5g6h
This shows the commit message, author, date, and diff for that commit. Work through the dangling commits until you find the most recent one from your deleted branch.
A faster way to get just the commit message for each:
git log –oneline e4f5g6h
This shows the commit and its ancestors, giving you enough context to identify the right one.
Step 3 — Recreate the Branch
Once you’ve identified the correct commit hash:
git checkout -b feature/login e4f5g6h
When Is git fsck Needed Instead of git reflog?
git fsck is more powerful but slower and harder to read than git reflog. Use it when:
The reflog doesn’t contain the commit you’re looking for (because too much time passed or the reflog was reset).
You’re working on a fresh clone of the repository where the reflog doesn’t have the full history.
You deleted commits using a more destructive operation and the reflog isn’t showing the right history.
You want to verify that all commits from a deleted branch are still accessible in the object database.
For most day-to-day “I just deleted a branch by accident” scenarios, git reflog is faster and more intuitive. git fsck is the backup option.
Method 4 — Restore From a Colleague’s Machine
This method is the most human of all the recovery options, and it’s worth mentioning because people overlook it.
If a teammate was working on the same branch, or if they pulled the branch before you deleted it, a complete copy of the branch exists on their machine. Recovering from their copy is often faster than digging through the reflog — especially for large branches with many commits.
Step 1 — Ask Your Colleague to Push the Branch
Have your colleague push their copy of the branch to the remote:
git push origin feature/login
If the branch doesn’t exist on the remote anymore (it was deleted there too), this creates it fresh from their local copy. If the remote branch still exists, this updates it.
Step 2 — Pull the Branch Locally
Once the branch is on the remote:
git fetch origin
git checkout feature/login
Or explicitly:
git checkout -b feature/login origin/feature/login
Your local copy is now identical to your colleague’s copy.
What If the Colleague Also Deleted It?
Then you’re both relying on the reflog and git fsck methods. But in a team environment with regular pushes, the likelihood of both the remote and all local copies being gone simultaneously is low — especially if the branch had any activity in the last few weeks.
Using a Colleague’s Local Branch Without Pushing to Remote
If you want to be more surgical and not push to the remote yet, your colleague can export the branch as a patch file and send it to you:
On their machine:
git format-patch main..feature/login –stdout > feature-login.patch
Send you the patch file. On your machine:
git checkout -b feature/login
git am feature-login.patchThis recreates all the commits from the branch on your machine without touching the remote at all.
Method 5 — Restore From a Stash or Tagged Commit
Two less common but useful scenarios for branch recovery:
If You Stashed Changes From the Deleted Branch
If you ran git stash while on the branch before deleting it, the stashed changes are still accessible. Your stash is independent of branches — it survives branch deletion.
List your stashes:
git stash list
You’ll see entries like:
stash@{0}: WIP on feature/login: e4f5g6h Add password hashing
stash@{1}: WIP on main: a1b2c3d Latest stable commitCreate a new branch from the stash:
git stash branch feature/login stash@{0}
This creates a new branch named feature/login at the commit where the stash was made, and pops the stash onto it. Your working directory will have the stashed changes applied.
If the Branch Was Tagged
If anyone ever tagged a commit on the deleted branch — for a release, a milestone, or a checkpoint — that tag still exists and points to the commit. Tags are independent references, like branches, and deleting the branch doesn’t delete the tag.
Find relevant tags:
git tag
Recreate the branch from the tag:
git checkout -b feature/login v1.2-beta
Replace v1.2-beta with the actual tag name.
What to Do Immediately After Accidentally Deleting a Branch
The first few seconds after accidental deletion matter. Here’s the exact sequence of steps to take, in order:
Step 1 — Don’t panic and don’t run any other Git commands yet.
Every command you run after a deletion moves HEAD and adds new entries to the reflog, which pushes older entries down. The deleted branch’s commits are safe — but don’t bury them further by running a bunch of other commands first.
Step 2 — Check if Git told you the hash.
When you ran git branch -d or git branch -D, did the output include a hash? Like:
Deleted branch feature/login (was e4f5g6h).
If yes, that’s your recovery hash. Use it immediately:
git checkout -b feature/login e4f5g6h
Done. No reflog needed.
Step 3 — If you don’t have the hash, open the reflog.
git reflog
Find the most recent commit from the deleted branch. It’ll be near the top of the output if you just deleted the branch. Copy the hash.
Step 4 — Recreate the branch.
git checkout -b feature/login COMMIT-HASH
Step 5 — Verify.
git log --oneline feature/login
git checkout feature/loginConfirm all commits are there and files are as expected.
Step 6 — Push to GitHub to preserve the recovery.
git push origin feature/login
Even if you weren’t done with the branch, pushing it preserves the work on the remote so it’s safe even if something happens to your local machine.
Real Terminal Example — Full Recovery Session
Here’s a complete session showing a realistic scenario: a developer deletes a feature branch before realizing it hadn’t been fully reviewed, panics, and recovers it cleanly.
$ git branch
- main
feature/dashboard
feature/user-profile
$ git log –oneline feature/user-profile
d4e5f6g Add avatar upload functionality
c3d4e5f Add profile bio field
b2c3d4e Add user profile page
a1b2c3d Initial user profile structure
[Thought this was merged. Deleting it to clean up.]
$ git branch -d feature/user-profile
error: The branch ‘feature/user-profile’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D feature/user-profile’.
[Git warned us. But we pressed on anyway.]
$ git branch -D feature/user-profile
Deleted branch feature/user-profile (was d4e5f6g).
[And immediately realized the avatar upload was never in the PR. It’s gone from the branch list.]
$ git branch
- main
feature/dashboard
[Okay. Time to recover. First — Git gave us the hash: d4e5f6g]
$ git checkout -b feature/user-profile d4e5f6g
Switched to a new branch ‘feature/user-profile’
$ git log –oneline
d4e5f6g (HEAD -> feature/user-profile) Add avatar upload functionality
c3d4e5f Add profile bio field
b2c3d4e Add user profile page
a1b2c3d Initial user profile structure
[All four commits recovered. Avatar upload is back.]
$ git status
On branch feature/user-profile
nothing to commit, working tree clean
[Files are exactly as they were before the deletion.]
$ git push origin feature/user-profile
Enumerating objects: 23, done.
Counting objects: 100% (23/23), done.
Delta compression using up to 8 threads
Compressing objects: 100% (18/18), done.
Writing objects: 100% (23/23), 4.27 KiB | 4.27 MiB/s, done.
To https://github.com/devteam/app.git
- [new branch] feature/user-profile -> feature/user-profile
[Branch is back on GitHub. Total recovery time: under two minutes.]
Now a second scenario — the reflog approach for when Git didn’t print the hash:
$ git branch -D feature/payments
Deleted branch feature/payments (was 3f4e5d6).
[Didn’t notice the hash. Terminal scrolled past it.]
[Some time passed, ran a few other commands]
$ git reflog
9a8b7c6 HEAD@{0}: commit: Hotfix login redirect
8b7c6d5 HEAD@{1}: checkout: moving from feature/payments to main
3f4e5d6 HEAD@{2}: commit: Add Stripe webhook handler
2e3d4c5 HEAD@{3}: commit: Add payment intent creation
1d2c3b4 HEAD@{4}: commit: Add payment route structure
0c1b2a3 HEAD@{5}: checkout: moving from main to feature/payments
[Found it. HEAD@{2} is the last commit on feature/payments — hash 3f4e5d6]
[And HEAD@{3} and {4} are earlier commits on the same branch]
$ git checkout -b feature/payments 3f4e5d6
Switched to a new branch ‘feature/payments’
$ git log –oneline
3f4e5d6 (HEAD -> feature/payments) Add Stripe webhook handler
2e3d4c5 Add payment intent creation
1d2c3b4 Add payment route structure
[All three commits recovered. Branch restored.]
How to Prevent Accidental Branch Deletion
Recovery is possible, but prevention is better. These habits reduce the chance of ever needing to recover a branch in the first place.
Tip 1 — Always Read the Git Warning Before Force Deleting
When you run git branch -d on an unmerged branch, Git prints:
error: The branch ‘feature/xyz’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D feature/xyz’.
This warning exists for a reason. Read it every time. If you’re not certain the branch is fully merged, don’t switch to -D immediately. Take a moment to check git log or look at the PR status first.
Tip 2 — Push Your Branch Before Deleting It Locally
If you’re about to delete a branch locally, push it first:
git push origin feature/login
Even if the work isn’t done, having a copy on the remote means recovery is a simple git checkout away. This habit costs nothing and creates a safety net.
Tip 3 — Use git branch -d (Lowercase) Instead of -D
The lowercase -d flag is the safe delete. It refuses to delete a branch that hasn’t been fully merged. The uppercase -D is force delete. It will delete the branch regardless of merge status. Make a conscious habit of starting with -d and only upgrading to -D when you’ve verified the branch is safe to remove.
Tip 4 — Don’t Immediately Delete Branches After a Merge
GitHub’s “Delete branch” button appears right after a pull request is merged, making it tempting to clean up immediately. Resist the impulse for 24 hours. Let the merged code sit in production (or the next environment) for a bit before cleaning up the branch. GitHub’s “Restore branch” button will be available if you realize something was missed.
Tip 5 — Tag Important Commits Before Deleting Branches
If a branch contains work that feels significant — a feature release, a major refactor, a milestone — tag the tip commit before deleting the branch:
git tag v2.1-feature-login feature/login
git branch -d feature/login
The tag persists independently of the branch. Even after the branch is deleted, the tagged commit is fully accessible and won’t be garbage collected.
git checkout -b feature/login v2.1-feature-login
One command to bring it all back.
Tip 6 — Protect Important Branches on GitHub
For branches that should never be accidentally deleted — main, develop, release, hotfix — enable branch protection rules on GitHub.
Go to Repository → Settings → Branches → Add branch protection rule.
Enter the branch name pattern (main, develop, release/*) and check:
Require pull request reviews before merging
Include administrators
Do not allow force pushes
With these rules, even repository administrators can’t delete or force-push to the protected branch. It’s a fundamental safeguard for branches that represent your production codebase.
Tip 7 — Regularly Back Up Work-in-Progress Branches
Make it a habit to push your feature branches to the remote at the end of every working day. Even if the code isn’t ready for review, having it on the remote means a local deletion is always recoverable with a simple git fetch and git checkout.
A simple end-of-day habit:
git push origin –all
This pushes all local branches to the remote. Your work is safe even if your laptop dies overnight.
FAQ
Q: I deleted a branch and I can’t find it in the reflog. Is the work gone?
Not necessarily. First, search the reflog more carefully:
git reflog –all
The –all flag includes reflog entries from all refs, not just HEAD. This sometimes surfaces commits that HEAD-only reflog doesn’t show.
If that doesn’t help, try git fsck:
git fsck –lost-found
This lists all dangling commits in the object database, regardless of reflog. If the branch’s commits were ever part of your repository, they’ll appear here (as long as git gc hasn’t run and cleaned them up).
Q: How long do I have to recover a deleted branch?
For commits referenced in the reflog, you have the full reflog retention period — 90 days by default for reachable commits, 30 days for unreachable ones. After that, git gc can remove them.
For dangling commits not in the reflog, they can be removed by git gc after 2 weeks by default. Running git gc manually or having it triggered by a large push can accelerate this.
The practical answer: recover the branch as soon as you notice it’s gone. The sooner you act, the more options you have.
Q: Git says “already exists” when I try to recreate the branch. What do I do?
error: A branch named ‘feature/login’ already exists.
This means a branch with that name still exists — perhaps you already partially recovered it, or the branch wasn’t actually deleted. Check:
git branch -a
The -a flag lists both local and remote branches. If the branch is listed, check out the existing one:
git checkout feature/login
If it’s listed as a remote branch only:
git checkout -b feature/login origin/feature/login
Q: I accidentally deleted main. Is that recoverable?
Yes, with the same approach — find the last commit on main using git reflog or the hash Git printed when you deleted it, and recreate it:
git checkout -b main COMMIT-HASH
Or if you’re not on main currently:
git branch main COMMIT-HASH
Then push it back to GitHub if needed (this will require a force push since you’re recreating a branch the remote thinks is gone):
git push –force origin main
Note: on GitHub, main is often protected by branch protection rules, which means it can’t be deleted or force-pushed to without admin privileges. If you can’t delete main, that protection is working correctly.
Q: A teammate deleted the branch on GitHub and I don’t have it locally. Can I recover it?
If the branch was deleted on GitHub but no one locally has it either, GitHub’s “Restore branch” button (on the merged pull request) is your best option. It’s available for a limited period after deletion.
If the button isn’t there, check if any of your teammates who worked on the branch have a local copy. Even if they deleted the remote branch, they might still have their local copy. Ask them to push it back.
If neither option is available, contact GitHub Support. For paid plans especially, GitHub support can sometimes restore deleted branches from their backups within a short window after deletion.
Q: Does git branch -d delete the commits too?
No. As explained at the beginning of this guide, a branch is just a pointer — a named reference to a commit. Deleting the branch deletes the pointer, not the commits. The commits remain in the repository’s object database. They become “dangling” (not reachable from any branch) but are still physically present until git gc cleans them up. That’s what makes recovery possible.
Q: Can I recover a branch on GitHub without using the command line?
Yes, in two ways. First, the “Restore branch” button on the pull request page (if available). Second, the GitHub API — if you know the SHA of the last commit on the deleted branch, you can recreate the branch through the GitHub REST API:
POST /repos/{owner}/{repo}/git/refs
Body: {“ref”: “refs/heads/feature/login”, “sha”: “COMMIT-HASH”}
This is useful for automation or when command-line access is unavailable.
Q: What if I deleted the branch and I never committed the work?
This is the one scenario where recovery is genuinely difficult. If you had changes in your working directory that were never committed, deleting the branch doesn’t affect those changes — they’re in the working directory, not in the branch. But if you also deleted those files or they got overwritten, and they were never committed or stashed, they may be unrecoverable through Git.
This is why committing early and often matters. Even a rough WIP commit (“work in progress — not ready”) preserves your work in the commit history and makes it recoverable through the reflog.
Q: Should I run git gc after recovering a branch?
Not immediately. Running git gc after recovery is fine in general, but don’t run it right after a deletion before you’ve verified the recovery is complete. git gc prunes unreachable objects and could remove the commits you’re trying to recover if they’re not yet attached to a branch. Complete the recovery first (recreate the branch, verify all commits are there), and only then run maintenance commands.
Related Errors and Situations
These come up in the same context as branch deletion and recovery.
error: The branch ‘feature/xyz’ is not fully merged.
This is a protection, not an error. Git is warning you before you delete a branch that contains commits not in the current branch. Stop. Verify whether the branch was actually merged. Use git log main..feature/xyz to see commits in the feature branch that aren’t in main. If there are commits you haven’t reviewed, this warning saved your work.
fatal: A branch named ‘feature/xyz’ already exists.
When trying to recreate a deleted branch and getting this error — the branch wasn’t actually deleted, or you’ve already partially recovered it. Run git branch -a to see all local and remote branches.
error: pathspec ‘feature/xyz’ did not match any file(s) known to git
You’re trying to checkout a branch that no longer exists. Either use git reflog to find the commit hash and recreate it, or check git branch -a to see available branches.
warning: refname ‘feature/xyz’ is ambiguous
Appears when a branch and a tag have the same name. Use explicit refs to avoid ambiguity:
git checkout refs/heads/feature/xyz
git push rejected after recreating a deleted remote branch
If you deleted a remote branch and then recreated it locally with a different history (different commits), pushing will be rejected because the remote branch history diverged. If you’re certain the new local version is correct:
git push –force origin feature/xyz
Commits visible in reflog but git checkout fails
This can happen if the git gc process ran and cleaned up the commits before you could recover them. If the hash shows in reflog but git show HASH returns “bad object,” the commit was garbage collected and may be unrecoverable.
Conclusion
If you came here in a panic because you just deleted a branch and can’t find your work — take a breath. The steps are clear, the recovery is usually fast, and Git’s design means the data is almost certainly still there.
The single most useful thing to remember is this: when Git says “Deleted branch feature/xyz (was HASH)”, that hash is your recovery key. Write it down, copy it, screenshot it. One command brings the branch back:
git checkout -b feature/xyz HASH
If you missed the hash, git reflog is the next stop. It’s Git’s personal diary, and it almost always has what you need for recent deletions.
The broader lesson here is one of the most reassuring things about Git once you internalize it: deleting a branch is one of the safest-feeling dangerous operations in all of version control. It feels permanent. It looks permanent. But it rarely is. The commits are still there, the reflog remembers where you’ve been, and the recovery path is well-worn.
That said, recovery is a safety net, not a strategy. The prevention habits in this guide — pushing before deleting, using -d instead of -D by default, enabling branch protection rules on GitHub, tagging important commits — are the things that make recovery unnecessary most of the time.
The best version of this situation is the one where you never need this guide. But now that you’ve read it, you have both the safety net and the prevention habits to make that much more likely.
Go recover your branch. It’s waiting.
Related Resources
Git Official Documentation — git-branch
Git Official Documentation — git-reflog
Git Blogs – Acollection of git articles from prodopshub.com
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.