Photo by Sean Dogjani on Unsplash

I was doing a routine git branch -a one afternoon and counted 47 branches. Forty-seven. Our team had maybe 8 active ones. The rest were dead, merged, deleted off the remote weeks ago — but there they were, just hanging around on my machine like they paid rent. I knew I'd done a git fetch earlier that day. I figured it would clean things up. It didn't.

That's the trap. Most people assume git fetch keeps everything in sync — including deletions. Totally reasonable assumption. Wrong one. Git is conservative by default. It pulls new stuff down, updates refs you already have, but it will not automatically remove remote-tracking branches that no longer exist on the server. You have to explicitly tell it to do that. And that's where git fetch --prune comes in.

Sound familiar? Let's get into it.

What the stale branch mess looks like

Run this and you'll see the problem immediately:

$ git branch -a

* main
  remotes/origin/main
  remotes/origin/feature/old-login-redesign
  remotes/origin/fix/typo-in-readme
  remotes/origin/feature/abandoned-in-2022
  remotes/origin/hotfix/that-one-friday-incident
  remotes/origin/johns-test-branch-delete-me

Half those branches are gone from GitHub or GitLab. The team deleted them after merging. But your local Git still has the remote-tracking refs sitting in .git/refs/remotes/origin/ doing absolutely nothing useful. And if you're using any kind of IDE branch switcher or git GUI, this list becomes a nightmare to navigate.

Photo by Seshu B. on Unsplash

Why git fetch alone doesn't clean this up

Here's the thing — Git's default fetch behavior is additive. It goes out, grabs new commits, updates branches that exist on both ends. But it deliberately does not delete local references to remote branches that have been removed. The reasoning is that git doesn't want to surprise you by silently removing refs you might care about.

Honestly, I get it. But in practice, 99% of the time those stale refs are just noise. Nobody is going back to remotes/origin/johns-test-branch-delete-me. It's dead. Let it go.

The technical name for these is "stale remote-tracking branches" — local refs that used to point at something on the remote but the remote side is gone. Git just... keeps the corpse around until you tell it otherwise.

Fix 1: Run git fetch --prune right now

The immediate fix is simple:

git fetch --prune

Or if you want to target a specific remote (most people have origin but you might have more):

git fetch --prune origin

What this does is fetch as normal, then compare your local remote-tracking refs against what actually exists on the remote. Anything that's gone on the remote side gets pruned from your local ref list. You'll see output like:

From https://github.com/yourteam/yourrepo
 - [deleted]         (none)     -> origin/feature/old-login-redesign
 - [deleted]         (none)     -> origin/fix/typo-in-readme
 * [new branch]      staging    -> origin/staging

That's it. Clean. The [deleted] lines are your stale refs getting pruned. Important to note — this only removes the remote-tracking refs. If you had checked out one of those branches locally and it still exists as a local branch, that's untouched. We'll get to that in a second.

Fix 2: Set prune to run automatically on every fetch

Honestly, just do this. One time. Never think about it again.

git config --global fetch.prune true

That sets it globally across every repo on your machine. Now every time you run git fetch or git pull, pruning happens automatically. No flags, no remembering, no 47-branch disasters.

If you'd rather set it per-repo (maybe you have a specific repo where you want more control):

git config fetch.prune true

Run that inside the repo without --global. Personally I just set it globally. I've never had a situation where automatic pruning caused a problem. It's the sane default Git probably should have shipped with.

Fix 3: Clean up stale local branches that tracked deleted remotes

Here's what --prune won't do — delete local branches that you checked out from those now-dead remotes. If you ran git checkout feature/old-login-redesign at some point, you've got a local branch by that name. Pruning removes the remote-tracking ref, but your local branch is still there.

To find those orphaned local branches, run:

git branch -vv | grep ': gone]'

Output looks like:

  feature/old-login-redesign  a3f92b1 [origin/feature/old-login-redesign: gone] Final tweaks
  fix/typo-in-readme          8cd01a2 [origin/fix/typo-in-readme: gone] Fix typo

The : gone] means the upstream tracking branch is gone. These are your orphans. Delete them with:

git branch -d feature/old-login-redesign
git branch -d fix/typo-in-readme

If git complains that changes aren't merged and you're absolutely sure you don't need them, force it with -D. But double check first. Losing local work that way is a bad afternoon.

If you want to automate the whole sweep, this one-liner works but I'd run it on a fresh machine before trusting it on something critical:

git branch -vv | grep ': gone]' | awk '{print $1}' | xargs git branch -d

Fallback tip: Use git remote prune if fetch isn't an option

Sometimes you're in a weird state — maybe you're offline, or you just want to prune refs without fetching new data. There's a command for that:

git remote prune origin

Add --dry-run if you want to see what would get pruned before actually doing it:

git remote prune --dry-run origin

This compares your local remote-tracking refs against the last known state of the remote without making a new network call. Useful. Not something most people know about.

Look, this whole thing is one of those Git paper cuts that nobody talks about because it doesn't break anything immediately. It just quietly makes your development environment noisier and harder to work in. The fix takes thirty seconds. Set fetch.prune true globally, run a one-time prune right now, clean up any orphaned local branches, and move on with your life. Your future self doing a git branch -a at 2am will be genuinely grateful.