必须显式执行git push origin --delete，因git设计上本地与远程状态分离；删本地分支不影响远端，需推送空引用通知服务端删除，删后须git fetch -p清理本地缓存的远程跟踪引用。
git push origin --delete 为什么必须显式执行
远程分支不会因为本地删了就自动消失，Git 的设计里「远端状态」和「本地状态」是分离的。你运行 git branch -d feature/login 只影响本地仓库，远端 origin/feature/login 依然存在，别人 git pull 还能拉下来，协作中容易造成混乱。
真正通知远端删除的，只有推送一个空引用过去：git push origin --delete feature/login。这个命令本质是把一个空 commit ID（即 0000000...）推到远端该分支名下，服务端识别后直接移除引用。
- 旧写法
git push origin :feature/login虽然等效，但冒号位置极易打错（比如写成: feature/login多个空格），且语义模糊，2026 年已不建议用 - 分支名含斜杠（如
release/v2.3.1）无需加引号，shell 正常解析；但若含空格或特殊字符（极少见），才需单引号包裹 - 如果远端返回
remote: error: unable to delete: protected branch，说明该分支被仓库设置为「受保护」，得先去 GitHub/GitLab 后台关掉保护策略
删完远程分支，为什么 git branch -r 还能看到它
这是最常见的「假残留」现象：远程分支确实已被删干净，但你的本地仓库还缓存着旧的远程跟踪引用。这不是 bug，是 Git 的 fetch 缓存机制导致的——它不会自动同步远端变更，除非你主动刷新。
清理方式只有一条命令：git fetch --prune（简写 git fetch -p）。它会对比远端当前真实分支列表，把本地多出来的 origin/xxx 引用全部删掉。
- 别用
git remote prune origin—— 它效果相同，但不如fetch -p直观，且部分老旧 Git 版本对它的支持不稳定 - 如果你刚删完远程分支就立刻跑
git branch -r，大概率看到的还是旧列表；必须先fetch -p，再查才准 - 某些 IDE（如 VS Code）的 Git 面板可能缓存更久，需要手动触发「Fetch」或重启面板
如何安全判断一个远程分支是否真的可以删
不能光看分支名“过时”就删。关键要看它有没有未合入主干的提交。误删未合并分支，等于永久丢失代码。
最可靠的方式是本地先同步远端最新状态，再做提交范围比对：
git fetch origin git log origin/main..origin/feature/old-ui
如果没输出，说明 feature/old-ui 的所有提交都已在 main 中；如果有输出，说明还有未合并内容，不该删。
- 把
main换成你实际的主干分支名（比如master、develop） - 注意用双点语法
..，不是三点...；三点是找共同祖先的对称差集，不适合判断是否已合并 - 如果分支长期没人动，也建议顺手跑
git ls-remote origin feature/old-ui确认它是否还存在于远端（避免本地引用过期导致误判）
批量删远程分支时最容易踩的坑
批量操作省事，但风险集中。比如用 git branch -r | grep 'feature/' | sed 's/origin\///' | xargs -I {} git push origin --delete {} 这类管道命令，一旦中间环节出错（如分支名含空格、匹配到不该删的分支），就会连环误删。
更稳妥的做法是分两步：先生成待删列表并人工核对，再执行。
- 生成清单：
git branch -r | grep 'feature/' | sed 's/origin\///' | sort - 复制结果，用编辑器逐行检查，删掉不想动的（比如
feature/release-candidate） - 保存为
to-delete.txt，再用xargs -I {} git push origin --delete {} - 每删完一个，加个
sleep 0.5避免触发 Git 服务端限流（尤其在 GitLab 自建实例上）
真正的难点不在命令怎么写，而在于确认「哪些分支属于可删范畴」——这需要团队有明确的分支命名规范和生命周期管理策略，否则技术手段再强也救不了混乱的协作习惯。
