Git remote branch deleted, but still it appears in 'branch -a'
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
If a branch was deleted on the remote but still appears in git branch -a, you are usually looking at a stale remote-tracking reference in your local repository. Git does not automatically delete every obsolete remote-tracking branch until you fetch with pruning or prune the remote manually.
Why the Deleted Branch Still Shows Up
git branch -a lists:
- local branches
- remote-tracking branches such as
remotes/origin/feature-x
That remotes/origin/feature-x entry is not the live remote branch itself. It is your local record of what the remote looked like the last time you fetched. If someone deletes the branch on GitHub or another server, your local tracking ref remains until Git updates and prunes it.
The Usual Fix: Fetch with Prune
Run:
Then check again:
If the branch was truly deleted on origin, the stale remotes/origin/... entry should disappear.
This is the most common and safest fix because it updates refs from the remote and removes tracking refs that no longer exist there.
Alternative: Prune the Remote Explicitly
You can also use:
This removes stale remote-tracking references without doing a full fetch of new data. In practice, many developers prefer git fetch --prune because it both updates and cleans up in one step.
Distinguish Remote-Tracking Branches from Local Branches
Sometimes the confusion is not about a stale remote-tracking branch at all. You may also still have a local branch with the same name:
If git branch -vv shows something like [origin/feature-x: gone], that means your local branch still exists but its upstream remote branch has been deleted.
If you no longer need that local branch, delete it explicitly:
If Git says the branch is not fully merged and you are sure you want it removed:
Use -D carefully because it forces local deletion.
Make Pruning Automatic
If you want stale remote-tracking refs cleaned up during normal fetches, enable pruning globally:
Or only for one repository:
After that, ordinary git fetch calls will also prune deleted remote branches.
Verify What the Remote Actually Has
If you want to compare your local view with the remote directly, run:
This asks the remote for its current branch heads. If the branch is absent there but present in git branch -a, your local tracking ref is stale and pruning is the correct fix.
A Typical Cleanup Workflow
Interpret the result like this:
- stale
remotes/origin/...entries disappear after prune - local branches remain until you delete them
- local branches marked
goneare still yours and need separate cleanup if unwanted
That distinction prevents accidental deletion of local work when you only meant to refresh remote state.
Common Pitfalls
- Assuming
git branch -ashows only live remote branches. It also shows your local remote-tracking refs, which can become stale. - Deleting the branch on the server and expecting local refs to vanish automatically. Git needs a fetch with pruning or a remote prune command.
- Confusing a stale remote-tracking branch with a still-existing local branch. Check
git branch -vvbefore deleting anything. - Using force deletion on a local branch when you only intended to remove the stale remote-tracking reference. Prune first, then decide whether local cleanup is needed.
- Forgetting to enable
fetch.prunein repositories where branches are created and deleted frequently. Automatic pruning reduces this class of confusion.
Summary
- A deleted remote branch can still appear in
git branch -abecause your local remote-tracking ref is stale. - '
git fetch --prune originis the standard fix.' - '
git remote prune originalso removes stale tracking refs.' - Local branches are separate from remote-tracking branches and may need manual deletion.
- '
git config fetch.prune truehelps keep branch listings clean over time.'

