Introduction

git fetch origin updates your remote-tracking references, but by default it may leave behind local references to remote branches that no longer exist on the server. To clean those up, you want pruning as part of the fetch workflow.

What gets deleted and what does not

When a branch is deleted on the remote, your local repository may still keep a remote-tracking reference such as origin/feature-x. That reference is not a normal local branch; it is Git's cached view of the remote branch.

Fetching with pruning removes those stale remote-tracking refs:

git fetch --prune origin

After that, origin/feature-x disappears locally if the branch really no longer exists on origin.

Importantly, this does not automatically delete your own local branch named feature-x. Pruning affects remote-tracking references, not normal local work branches.

Why plain git fetch is not enough

A regular fetch downloads new remote information, but stale references can remain because Git does not assume you want them deleted automatically.

That means you can end up with confusing output from commands such as:

git branch -r

You might still see branches that were deleted upstream days ago, even though the server no longer has them.

Make pruning part of your normal workflow

If you want this behavior every time, turn it on permanently:

git config --global fetch.prune true

Now a normal fetch behaves like this:

git fetch origin

with stale remote-tracking branches cleaned up automatically.

You can also prune a specific remote explicitly:

git remote prune origin

That command removes stale refs without doing a new fetch.

Checking what changed

A typical cleanup workflow looks like this:

git branch -r
git fetch --prune origin
git branch -r

Comparing the before and after lists makes it obvious which remote-tracking branches were stale. This is especially helpful in long-lived repositories where merged feature branches are deleted frequently and old remote refs become visual noise.

If you also want to delete a local branch that is no longer needed, do that separately. This distinction is important in collaborative repositories because remote cleanup and local cleanup often happen on different timelines:

git branch -d feature-x

or, if it has unmerged work you intentionally want to discard:

git branch -D feature-x

In busy repositories, making pruning routine also improves command output quality. Branch lists, completion suggestions, and remote-tracking references become much easier to read when stale branches are not left around for months.

Common Pitfalls

The biggest mistake is thinking git fetch --prune deletes normal local branches. It does not. It only removes stale remote-tracking refs such as origin/feature-x.

Another issue is confusing origin/feature-x with feature-x. They may have similar names, but one is Git's view of the remote and the other is your own local branch.

Be careful when deleting local branches after pruning. A remote branch disappearing does not automatically mean your local branch is safe to delete; it may still contain work you care about.

Finally, if you use multiple remotes, prune the correct one. Deleting stale refs from origin does not affect stale refs from upstream or any other remote.

Summary

• Use git fetch --prune origin to update from origin and remove stale remote-tracking branches.
• Pruning deletes refs like origin/feature-x, not your local feature-x branch.
• Enable fetch.prune if you want this behavior on every fetch.
• 'git remote prune origin removes stale remote refs without fetching new data.'
• Delete local branches separately and deliberately. Pruning is a reference cleanup tool, not a substitute for branch management policy.