Deleted remote Git branch still listed? Preview pruning and keep local work

By ON Lab · Sources checked November 8, 2026

A deleted server branch can remain in git branch -a as a stale remote-tracking reference such as remotes/origin/topic. First confirm the remote and preview pruning with git remote prune --dry-run origin. For a normal branch-fetch configuration, git fetch --prune origin refreshes the remote information and removes stale remote-tracking branches. A local branch named topic is a separate reference and can remain.

This guide addresses a branch that was intentionally deleted on the remote but is still listed locally. It does not tell you to delete work or rewrite a shared branch. We reproduced the distinction using a disposable local bare repository and clone on macOS. No hosted repository, private source code or personal Git configuration was changed.

Identify which branch you are looking at

git status --short
git branch
git branch -r
git branch -vv
git remote -v

git branch lists local branches. git branch -r lists your locally stored remote-tracking branches. git branch -a combines these views; it is not a fresh query of the server each time you run it.

Check git remote -v before using the example name origin. Your repository may use another name, or its fetch and push destinations may differ. Do not publish that output if it contains a private URL or credentials.

Check the server without deleting anything

git ls-remote --heads origin refs/heads/topic
git remote prune --dry-run origin
git config --get-all remote.origin.fetch
git config --get fetch.pruneTags
git config --get remote.origin.pruneTags

Replace topic with the exact branch name. A successful ls-remote query with no matching output indicates that this exact branch was not advertised by that remote. A failed query does not prove deletion: first resolve the connection or access error. The dry run reports what pruning would remove without applying that pruning.

An unset configuration key can produce no output and a nonzero status; distinguish that from a failed remote query. The usual branch-fetch mapping looks like +refs/heads/*:refs/remotes/origin/*. Inspect the actual mapping rather than assuming it. Git pruning follows refspecs. A custom mapping that fetches tags into refs/tags/*, or prune-tags configuration, changes the risk: local tags can be candidates too. If your preview includes tags or unfamiliar references, stop and review that configuration before continuing. The simple branch-only result below is not proof that a custom mirror configuration behaves the same way.

Refresh and prune the intended remote

After confirming the preview and configuration, choose the operation you need:

git fetch --prune origin

This fetches updates and prunes stale references according to that remote's configuration. If you only want pruning without fetching new references, the alternative is git remote prune origin. You do not need to run both just to remove the same stale remote-tracking branch.

Then inspect the separate lists again:

git branch -r
git branch
git branch -vv
git status --short

A remaining local topic branch is not evidence that remote pruning failed. Decide whether that local branch contains work you want to retain. Do not substitute git branch -D for this investigation: forced local deletion answers a different question. This article intentionally stops short of a local deletion recipe.

What our local reproduction actually showed

We created a server-side topic branch and a local tracking branch, then removed the server-side reference directly in our local fixture. An ordinary fetch left origin/topic in the clone. A successful exact ls-remote query returned no branch. The pruning dry run identified origin/topic but left it in the list, confirming that previewing was not the mutation.

After git fetch --prune origin, the remote-tracking list contained only origin/main. The local list still contained main and topic. Its verbose view marked the topic upstream as gone. A local-only tag and an untracked sentinel file remained. We checked their presence after pruning; we did not infer preservation from the command's exit code alone.

This is a test of ordinary branch refspecs in the recorded local Git environment. It does not exercise every hosting provider, access-control rule, mirror refspec or tag-pruning configuration. The official fetch documentation's pruning section is the reference for those variations.

If the stale name still appears

• Confirm whether it is a local branch or a remote-tracking entry. Read the separate lists instead of relying on a mixed view.
• Confirm which remote owns the reference. Pruning origin will not remove a stale entry stored under another remote.
• Read the complete fetch result. An authentication or network failure is not a completed refresh.
• Refresh the graphical client's branch view after checking the command-line result. Do not reclone solely because an old label remains visible in the interface.
• If the server still advertises the exact branch, investigate its actual deletion status rather than forcing a local cleanup to make the display agree.

Pruning is reference maintenance, not a way to move your current uncommitted edits between branches. If that is the symptom, see why uncommitted changes can follow a branch switch. Keeping these problems separate helps avoid deleting a useful local branch while trying to refresh the server's branch list.

Sources

• git-scm.com: source guidance
• git-scm.com: source guidance
• stackoverflow.com: source guidance