git remote prune origin 未删除远程分支引用，是因为它仅清理本地已确认在远程不存在的引用，前提是本地 fetch 记录已过期且远程确实已删该分支；应优先用 git fetch --prune 一步拉取并清理，或配置 fetch.prune=true 实现自动修剪。
git remote prune 为什么没删掉远程分支引用
执行 git remote prune origin 后，本地仍能看到已删除的远程分支（如 origin/feature-old），不是命令失效，而是它只清理 .git/refs/remotes/ 下「已确认不存在」的引用——前提是远程仓库真没了该分支，且你的本地 fetch 记录已过期。但 Git 默认不会自动更新远程引用列表，尤其当你长期没运行 git fetch --prune 或 git remote update --prune。
实操建议：
- 优先用
git fetch --prune origin：它先拉取最新远程状态，再删本地残留引用，一步到位 - 如果只想清理不拉代码，改用
git remote update --prune origin - 检查是否生效：运行
git branch -r，确认origin/xxx不再出现 - 注意配置项
fetch.prune：设为true可让每次git fetch自动 prune（git config --global fetch.prune true）
手动删除某个远程分支引用（比如 origin/bugfix-123）
有时你明确知道某分支已被合并且从远端删了，但本地还顽固留着，又不想全量 prune，就得精准清除。
实操建议：
- 直接删引用文件：
git update-ref -d refs/remotes/origin/bugfix-123 - 或用更安全的
git branch -r -d origin/bugfix-123（加-d是安全删除，若引用被其他 reflog 引用会拒绝；强制删用-D） - 别用
git push origin :bugfix-123：这是删远端分支，不是清理本地引用 - 删完可验证：
git show-ref | grep bugfix-123应无输出
远程仓库地址变了，旧 remote 还在引用里怎么办
重命名、迁移仓库后，git remote set-url 只改 URL，不清理旧 remote 的所有本地缓存（如 refs/remotes/oldname/、.git/config 中的 remote 段、甚至 FETCH_HEAD 历史记录）。
实操建议：
- 先删 remote 配置：
git remote remove oldname - 再删对应引用目录：
rm -rf .git/refs/remotes/oldname - 清理 reflog 中残留：
git for-each-ref --format='%(refname)' refs/remotes/oldname | xargs -I{} git update-ref -d {} 2>/dev/null - 最后运行
git gc --prune=now收尾（非必须，但能清理 dangling 对象）
为什么 git branch -r 显示的分支和 GitHub/GitLab 上看到的不一致
这不是 Git 故障，而是「远程分支引用」本质是本地快照：它只反映你上次 git fetch 时远端的状态。如果你很久没 fetch，而别人早已删掉分支，git branch -r 就会显示过期信息。
实操建议：
- 不要依赖
git branch -r判断远端真实状态，应以git ls-remote --heads origin为准（直连远端查 HEADs） -
git ls-remote输出的是 commit hash + 分支名，无歧义，且不依赖本地引用 - 想同步全部远程状态并清理：用
git fetch --all --prune - CI/CD 脚本中避免用
git branch -r做分支存在性判断，改用git ls-remote -q origin refs/heads/xxx检查单个分支
真正容易被忽略的是：Git 的「远程分支」根本不是实时镜像，它只是你本地的一份缓存快照。任何清理操作前，先确认你想要的是「删本地快照」还是「删远端资源」——这两个动作完全独立，混用就会白忙活。
