活跃分支的核心判断标准是是否仍在集成流程中流转，即CI是否运行、PR是否开启、最近72小时内是否被rebase或force-push；仅看git branch列表或提交时间易误判，需结合git for-each-ref、git ls-remote及CI/PR API交叉验证。
活跃分支 ≠ 有 commit 记录，僵尸分支 ≠ 名字老、没 push 过。判断核心在于「是否还在集成流程中流转」——CI 是否在跑、PR 是否开着、最近 72 小时内是否被 rebase 或 force-push 过。只看 git branch -a 列表或提交时间，90% 的误判都从这里开始。
用 git for-each-ref 看真实提交活跃度
本地分支的最后提交时间容易伪造（比如 git commit --amend 后再 push），但 git for-each-ref 直接读引用对象元数据，更可靠：
-
git for-each-ref --sort=-committerdate --format="%(committerdate:iso8601) %(refname:short)" refs/heads/：按 ISO 时间倒序列出本地分支，一眼看出哪些分支超过 7 天没动 - 注意
committerdate和authordate区别：rebase 会改authordate，但committerdate是实际合并/提交时间，更适合判断“谁真正在用这个分支” - 如果某分支
committerdate是 3 个月前，但 CI 状态仍是pending，它大概率是卡在 PR 流程里没合——不算僵尸，但得人工跟进
远程分支存活状态不能信 git branch -r
git branch -r 显示的是本地缓存的远程引用，不是实时状态。你看到的 origin/feature/login-v2 可能早被别人删了，只是你没 fetch 更新。
batch-git-url-replace
下载
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 真正验证远程分支是否存在：
git ls-remote --heads origin feature/login-v2—— 有输出哈希就是还活着，空返回说明已被删 - 查它的最后提交时间：
git show -s --format="%cd" $(git ls-remote --heads origin feature/login-v2 | awk '{print $1}')，再结合 CI/PR 系统 API 判断是否仍在流程中 - 别用
git fetch -p后就以为清理完了：git fetch -p只删本地对已删远程分支的引用，不删本地跟踪分支（git branch -d -r origin/xxx才能清干净）
靠 CI/PR 状态补全“活跃”定义
光看 Git 提交记录会漏掉关键信号。一个分支可能没新 commit，但 PR 正在被 review，或者 CI 正在跑 test-suite，这比“三天内有 commit”更能说明它还在流通。
- GitHub/GitLab API 可查：
/repos/{owner}/{repo}/pulls?state=open&head={branch}，返回非空 = 有未关闭 PR - CI 状态要看具体平台：GitLab CI 用
pipelines?ref={branch}&status=running，GitHub Actions 需查 workflow-runs - 如果 PR 已 close 但没 merge，且分支最后 commit 超过 72 小时 → 僵尸分支（除非明确标记为
wip或draft）
真正难的不是命令怎么写，而是把 Git 引用、CI 状态、PR 生命周期三条线串起来看。很多人卡在“这个分支看起来没动，但我不敢删”，问题往往出在没连上 CI/PR 系统做交叉验证——工具链断了一环，判断就只剩猜。
