Does deleting a branch delete its commits?

No. A branch is just a movable pointer to a commit. Deleting it removes the pointer; the commits stay in the object store until garbage collection, which is weeks away in practice.

The branch had a pull request. Is it recoverable?

Yes, easily — GitHub preserves PR commits under special refs even after the source branch is deleted. Closed PRs often show a 'Restore branch' button, and the commits tab lists every SHA regardless.

I deleted the branch locally AND on GitHub. Now what?

If you know the SHA (from reflog, a PR, CI logs, or the repo's activity feed), recreate a branch at that commit and push it. Without a SHA, a recovery scan of GitHub's activity events is the way to find it.

The branch was merged before I deleted it. Did I lose anything?

Nothing. Merging copied the commits into the target branch's history, so deleting the source branch only removed a redundant label. Your work is all in main already.

How to recover a deleted branch

Deleted a branch — locally, on GitHub, or both — and need it back? The commits almost certainly still exist. Here's where they went and how to get them back.

First, the fact that makes this whole guide short: a branch is just a pointer. Deleting one throws away a sticky note, not the work. The commits stay exactly where they were until git's garbage collector comes around — which is weeks away in practice.

So the question is never "are my commits gone?" It's "how do I find the SHA to point at again?"

Deleted locally, still on GitHub

Nothing to recover — the remote still has it:

git fetch origin
git checkout -b my-branch origin/my-branch

Deleted on GitHub, still in your local clone

Your clone remembers where the branch pointed:

git reflog

Find the SHA where the branch last sat, then recreate and push:

git branch my-branch abc1234
git push origin my-branch

If you had recently fetched the remote branch, git reflog show origin/my-branch can be even more direct.

Deleted on GitHub, but it had a pull request

This is the good-luck scenario. GitHub keeps every PR's commits alive under hidden refs (refs/pull/<number>/head) even after the source branch is deleted — sometimes for years.

Closed or merged PR? Look for the Restore branch button at the bottom. One click, done.
No button? The PR's commits tab lists every SHA. Take the newest one and create a branch at it.

Deleted everywhere, no PR, no local copy

The hard case, and the one that feels unrecoverable. The commits are on GitHub's servers but nothing points at them, and you don't know the SHA. Your best lead is GitHub's activity feed: branch deletions are recorded as events, and the event includes the SHA the branch pointed at when it died.

With that SHA, open https://github.com/<owner>/<repo>/commit/<sha> in a browser. Page loads → the commit is alive → create a branch at it via the API or ask git.tools to do it for you. 404 → garbage collection already ran, and the remaining hope is a teammate's clone.

The git.tools way

Find it with Rescue

Rescue scans your repo's GitHub activity for branch deletions, checks whether the deleted commits are still alive on GitHub, and restores them onto a fresh branch — even if your local clone never had them.

Open Rescue →

The one case where nothing was ever wrong

If the branch was merged before deletion, you lost nothing at all. The commits live on in the target branch's history; the deleted branch was only a label. GitHub even nudges you to delete merged branches for exactly this reason.

Thirty seconds of prevention

Recovery works because git is a hoarder, but hoarding has an expiry date. If a branch matters even slightly, bookmark it before you delete or rewrite anything — a named pointer costs nothing and turns every future recovery into a non-event.