git remote prune origin更可靠，因其直接扫描本地所有origin/xxx引用并逐个向远程发起head查询比对，不依赖refspec配置或fetch动作；而git fetch --prune仅在拉取时顺手清理，受fetch.prune配置、refspec限制及git pull不继承等影响易失效。
git remote prune origin 为什么比 git fetch --prune 更可靠
因为 git fetch --prune 只在 fetch 过程中“顺手”清理，而它能否真正识别哪些远程分支已不存在，取决于你当前的 refspec 配置。常见失效场景包括：
– git remote set-branches origin '*' 没配，导致 Git 默认只跟踪 main 和 develop，其他分支的本地引用压根不参与 fetch，也就无从 prune
– 你用的是 git pull，它不继承 fetch.prune 配置（哪怕全局设了 fetch.prune true）
– 远程仓库启用了 refspec 过滤（比如 CI 只同步特定分支），fetch --prune 就不会触碰被过滤掉分支的本地记录git remote prune origin 则完全不同：它直接扫描 .git/refs/remotes/origin/ 下所有文件，再逐个向远程发起 HEAD 查询，只要远程没这个 ref，就立刻删本地引用——不依赖 fetch 动作，也不看配置，纯靠事实比对。
删远程分支后，VSCode 分支列表还显示旧分支怎么办
这不是 UI 卡顿，也不是缓存没刷新，是 Git 扩展读取的分支数据和真实状态脱节了。VSCode 的「Git: Sync」命令不是实时调用 git branch -r，而是基于上一次 fetch 或 sync 时缓存的内存快照。
必须两步硬操作：
– 先运行 git remote prune origin（或替换成你的 remote 名，如 upstream）
– 再按 Ctrl+Shift+P（macOS 是 Cmd+Shift+P），输入并执行 Git: Sync
注意：只点界面上的「Fetch」按钮、或者重启 VSCode，都无效；git fetch --prune 后也大概率不更新 UI，必须显式触发 Sync。
批量删远程分支前，这三个检查不能跳过
直接 git push origin --delete branch1 branch2 容易引发团队事故，务必确认：
– 目标分支是否真已合并？用 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 少一半救火时间。
git filter-repo 清理大文件时最容易忽略的三件事
git-filter-repo 是目前最稳妥的历史清理工具，但实操中常因细节翻车：
– 它默认拒绝在非裸仓库里运行，别直接在日常开发目录下执行；更安全的做法是先 git clone --mirror 出一个裸仓库再处理
– --invert-paths 的语义容易误解：它不是“删除指定路径”，而是“保留除该路径外的所有内容”，所以删单个文件要写 git-filter-repo --path bigfile.so --invert-paths --force，不是 --path bigfile.so 单独用
– 操作后必须重推全部提交，且需强制推送：git push --force --all origin 和 git push --force --tags origin，否则远程仍保留旧历史对象，瘦身等于白做
另外，所有操作前必须完整备份项目文件夹（不是只 git clone），因为 git-filter-repo 会重写所有提交哈希，不可逆。
