git remote prune origin 未删除远程分支引用，是因为它仅清理本地已确认在远程不存在的引用，前提是本地 fetch 记录已过期且远程确实已删该分支；应优先用 git fetch --prune 一步拉取并清理，或配置 fetch.prune=true 实现自动修剪。
git remote prune 为什么没删掉本地的远程分支引用
执行 git remote prune origin 后，远程已删除的分支在 git branch -r 里依然显示（如 origin/feature-old），是因为这个命令只清理本地仓库中「已知过期」的远程引用缓存，但不会自动更新 refs/remotes/ 下的引用文件。它依赖上次 git fetch 时记录的远程状态，如果很久没 fetch，prune 就“看不见”新删的分支。
正确做法是先同步远端最新状态：
- 运行
git fetch --prune origin（推荐）—— 一步完成获取 + 清理 - 或分两步：
git fetch origin后再git remote prune origin - 注意：不加
--prune的git fetch默认不清理，这是最常被忽略的点
如何安全批量删除本地跟踪的远程分支引用
有时 git branch -r 显示一堆带 origin/ 前缀的“幽灵分支”，它们只是本地引用，并不对应任何远程 HEAD，但会干扰 git checkout 或 IDE 的分支列表。手动一个个删太慢，可以用脚本清理：
先预览将被删除的分支（务必先执行）：
git branch -r --format='%(refname:short)' | grep '^origin/' | while read b; do git ls-remote --heads origin ${b#origin/} | grep -q . || echo "stale: $b"; done
确认无误后执行删除：
git branch -r --format='%(refname:short)' | grep '^origin/' | while read b; do git ls-remote --heads origin ${b#origin/} | grep -q . || git update-ref -d $b; done
-
git ls-remote --heads origin feature-x返回空，说明远程已无该分支 -
git update-ref -d origin/feature-x是比git branch -d -r更底层、更可靠的删除方式 - 避免用
git branch -d -r origin/xxx，它对已失效的引用会报错“not found”
配置自动 prune 避免反复手动处理
每次 fetch 都手动加 --prune 容易忘，可以设为默认行为：
- 全局启用：
git config --global fetch.prune true - 仅对某个远程启用：
git config remote.origin.prune true - 效果等同于每次
git fetch origin都自动加上--prune - 注意：这不会影响
git pull，因为 pull 默认不继承 fetch 的 prune 行为；如需 pull 也 prune，得配pull.rebase或改用git pull --prune
IDE 或 Git GUI 工具里残留分支怎么处理
VS Code、JetBrains 系列或 Sourcetree 中仍能看到已删除的远程分支，不是 Git 本身问题，而是工具缓存了旧的 refs/remotes/ 数据。单纯重启无效，必须让 Git 先真实清理引用，再触发工具重载：
- 先运行
git fetch --prune origin - 再在 IDE 里执行 “Reload project” 或 “Refresh Git Repository” 类似操作
- 某些工具（如 older VS Code Git extension）需要关闭再打开文件夹才能清空分支缓存
- 别直接删
.git/refs/remotes/origin/下文件——可能破坏 Git 内部一致性
真正麻烦的从来不是删分支，而是团队协作中没人定期 git push --delete origin xxx，导致远端垃圾堆积；本地 prune 只是补救，上游规范才是根因。
