git fetch --prune（或 git fetch -p）是清理本地残留远程跟踪分支的唯一正确方法，它同步远程最新分支列表并自动删除已失效的 origin/xxx 引用，不删本地分支，也不影响提交对象。
远程分支不是“删了就完事”，它涉及本地引用残留、权限控制、团队协作节奏三个层面，漏掉任一环节都可能引发后续 fetch 失败或误操作。
git push origin --delete 与 git push origin :branch 的区别
两者效果一致，但语义和可读性不同：git push origin --delete feature/login 是 Git 2.0+ 推荐语法，明确表达“删除意图”；git push origin :feature/login 是旧式引用删除写法（冒号前为空表示“取消引用”），容易被误读为“推送空内容”。
实际项目中建议统一用 --delete，尤其在 CI/CD 脚本或团队共享文档里——避免新成员把 : 当成拼写错误而反复重试。
- 执行后仅移除远程仓库中的分支指针，该分支所有提交仍保留在对象库中（只要没被 GC 回收）
- 不会自动清理本地的
origin/feature/login追踪分支，需额外执行git fetch --prune - 若远程仓库启用了分支保护（如 GitHub 的 branch protection rules），即使有写权限也会报错
! [remote rejected] feature/login (protected branch hook declined)
删除后本地仍显示 origin/xxx 分支？这是引用残留
执行 git push origin --delete feature/old 后，运行 git branch -r 仍能看到 origin/feature/old，这不是 bug，是 Git 的设计行为：本地保留远程分支的“快照”，直到你显式同步元数据。
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
正确清理方式只有一种：git fetch --prune（或简写 git fetch -p）。它会拉取远程最新分支列表，并自动删除本地已不存在对应远程分支的追踪引用。
- 不要手动编辑
.git/packed-refs或.git/refs/remotes/origin/下文件——风险高且易出错 - 如果团队多人共用一个本地仓库（极少见），
--prune只影响当前用户，不干扰他人 - 某些 IDE（如 IntelliJ IDEA）的 Git 工具窗口不会自动触发 prune，需在 Terminal 手动执行或配置 “Fetch with prune” 选项
批量清理过期远程分支的实操边界
用脚本自动删远程分支前，必须确认两点：是否已合并、是否仍在活跃开发。盲目 git branch -r | grep -v 'main\|develop' | xargs -I {} git push origin --delete {} 极易误删。
推荐分步验证：
- 先查哪些远程分支已合并到
main：git branch -r --merged origin/main | grep 'origin/feature/' - 再过滤掉最近 7 天内有提交的分支（避免删掉刚合入但还没部署的）：
git for-each-ref --format='%(committerdate:iso8601) %(refname:short)' refs/remotes/origin/feature/* | awk '$1 - 最后对筛选结果执行删除，且每次只删 1 个并加
-n预览（dry-run）：echo "origin/feature/old" | xargs -I {} git push origin --delete {}
真正危险的不是命令本身，而是把“远程分支已删”等同于“任务已完成”——很多团队忘了通知协作者更新本地 remote tracking refs，导致下一次 git pull 报错 unable to update local ref。
