真正清理远程分支残留需执行git remote prune origin，它直接比对本地引用与远程真实状态并删除失效项；再在vscode中运行“git: sync”刷新ui缓存。
远程分支删了，git branch -r 里还挂着一堆 origin/feature/xxx？本地分支删完，VSCode 左下角分支列表里依然显示已合并的旧分支？这不是 UI 缓存问题，是 Git 本地引用没真正清理干净。
为什么 git fetch --prune 有时不生效
它只在执行 fetch 的同时“顺手”修剪，但前提是你的 fetch 配置能拉到完整远程引用。常见失效场景：
-
git remote set-branches origin '*'没配 —— Git 默认可能只跟踪部分分支，--prune就无从判断哪些该删 - 你用的是
git pull，而pull不继承fetch.prune配置（哪怕你设了fetch.prune true） - 远程仓库用了 refspec 过滤（比如只同步
main和develop），fetch --prune就不会碰其他分支的本地记录
真正可靠的做法是绕过 fetch，直接扫描并清理：git remote prune origin。它不依赖拉取动作，只比对本地 .git/refs/remotes/origin/ 下所有文件和远程真实状态，不存即删。
批量删远程分支前必须确认的三件事
别让 git push origin --delete 成为团队事故源头：
- 目标分支是否真已合并？用
git branch -r --merged origin/main而不是git branch --merged main—— 后者只查本地 commit DAG，可能漏掉只推了一半的分支 - 有没有人正基于该分支开发？
git log -1 --pretty=%ci origin/branch-name看最后推送时间，2 周内活跃的建议跳过或群内同步 - CI 是否还在监听该分支？GitHub/GitLab 的 webhook 或 CI 配置里可能硬编码了分支名，删完会触发失败构建
安全脚本开头加一句 git branch -r --merged origin/main | grep 'origin/' | sed 's/origin\///' | grep -vE '^(main|develop)$'，再人工过一遍输出，比直接管道进 xargs git push origin --delete 少一半救火时间。
VSCode 分支列表卡在旧状态怎么办
不是重启 VSCode，也不是点「Fetch」，是两步硬操作：
- 先运行
git remote prune origin（或git remote prune upstream，按你 remote 名改）—— 清 Git 层残留 - 再在 VSCode 中按
Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入「Git: Sync」并执行 —— 强制刷新 Git 扩展的内存缓存
注意：git fetch --prune 后 VSCode 可能仍不更新，因为它的分支选择器缓存的是上一次「Sync」时的数据，不是实时读取 git branch -r 输出。
删完远程分支，本地同名分支还在？
这是两个独立动作：删远程 ≠ 删本地。尤其当你在 main 上执行 git push origin --delete feature/login，feature/login 本地分支照常存在，且下次 git status 会提示「Your branch is based on 'origin/feature/login', but the upstream is gone」。
自动清理方案（推荐加到日常 workflow）：
- 删完远程后，立刻跑：
git branch --format='%(refname:short)' --merged main | grep -v '^main$' | xargs -I {} git branch -d {} 2>/dev/null - 或者更保守：先
git branch -vv | grep ': gone' | awk '{print $1}' | xargs git branch -d—— 只删那些明确标记为[gone]的本地分支
别依赖 git branch -d 的合并检查来保命：如果某分支只合入了部分提交，Git 仍可能判定为「已合并」，但业务逻辑其实不全。最终判断权永远在人，不在命令输出。
