判断分支是否该删，需综合最后一次提交时间、是否有open PR、是否被tag或release引用三者；缺一则进入观察期，超14天无活动且不满足任一条件即为僵尸分支。
怎么判断一个分支已经“活够了”
分支是否该删，不能只看有没有 merge —— 很多分支 push 后就再没人碰，却长期挂着。关键指标是「最后一次提交时间」+「是否有 open PR」+「是否被任何 tag 或 release 引用」。三者缺一，就该进入观察期。
-
git for-each-ref --sort=-committerdate --format="%(committerdate:iso8601)%09%(refname:short)" refs/heads/能按时间倒序列出所有本地分支，一眼扫出超过 14 天没动的 - 远程分支不能信
git branch -r的缓存结果，得用git ls-remote origin拿最新 commit hash，再git show -s --format="%cd" <hash>查真实时间 - GitHub/GitLab API 是唯一可信来源：查
/repos/{owner}/{repo}/pulls?state=open返回的head.ref，比本地分支列表更准
为什么 git branch -a 统计不准，还容易误报
git branch -a 只反映本地 ref 镜像状态，不感知远程实际活跃度。它会把已 merge 但未 prune 的分支、已关闭 PR 对应的分支、甚至被 force-push 覆盖过的历史分支全算进来，导致数字虚高。
- 执行
git fetch --prune后再跑git branch -a，才能剔除已从远端删除的分支 - 真正要监控的是「存活分支数」而非「总分支数」：存活 = 有 open PR 或最近 72 小时内有 commit 或 CI pipeline 正在运行
- CI 状态必须交叉验证：一个分支有 PR，但其 latest commit 的
checks连续失败 ≥2 次，实际已半死亡，不应计入活跃
用脚本自动识别僵尸分支并预警（最小可行版）
不需要复杂框架，一个 shell 脚本 + cron 就能跑起来。核心逻辑是：采集 → 判别 → 通知。重点不是功能全，而是稳定、可审计、不误杀。
- 判别条件示例：
feature/.*分支且committerdate:relative> 14 days 且无 open PR 且未被任何 tag 引用 → 标记为 zombie - 通知方式建议走企业微信或 Slack webhook，避免邮件延迟；内容必须带分支名、最后提交人、最后提交时间、关联 PR URL（如有）
- 脚本开头加
set -e和set -u，防止因某个命令失败导致后续误判；输出日志必须记录每条分支的判定依据，方便回溯
警报阈值设多少才不会天天吵人
阈值不是拍脑袋定的，得结合团队节奏。我们实测下来，14 天是多数团队的合理临界点：短于它，清理太激进；长于它，僵尸分支开始堆积风险。
- 警告级：单仓库中 zombie 分支数 ≥5 且持续 24 小时 → 发 Slack 提醒对应 repo owner
- 危急级：同一分支连续 3 次被标记为 zombie 且无人处理 → 自动发工单到 DevOps 群，并触发
git branch -d+git push origin --delete（需提前白名单保护 main / develop） - 注意：所有自动删除操作必须留 24 小时冷却期，且删除前写入 audit log，包括操作人、时间、分支名、判定依据
