最近整理 WAVE-app 的本地工作树时，我原本的目标很简单：让日常开发入口始终落在最新主分支上，把已经没用的历史分支清掉。真正开始检查后，事情却很快从“删几个旧分支”变成了一次 Git 状态治理。

最危险的判断方式其实是看名字和日期。一个分支很老，不代表它没东西；一个 PR 已经 merged，也不代表本地这条分支上没有后来追加的提交；一个 worktree 路径不存在，也不代表应该直接把关联引用一起删掉。于是清理流程被拆成了几层证据：先刷新远端引用，再检查每条本地分支相对主分支的 ahead/behind，比较等价提交和文件树差异，同时检查 worktree 是否仍存在、是否有未提交修改，最后再用 PR 合并状态交叉验证。

这次真正满足删除条件的只有一条已经合并、改动也等价进入主分支的本地分支。删除前先给它的提交打了恢复标签，再清理失效的 worktree 元数据，最后才删除分支本身。其余几条虽然看起来像“历史分支”，但仍保存着独立提交或脏工作树，因此全部保留。清理结束后再次 fetch，并确认日常使用的主目录仍在 master，与 origin/master 为 0 ahead / 0 behind。

这套过程比 git branch -D 麻烦得多，但它解决的是另一类问题：当一个项目同时被 IDE、Codex、临时 worktree 和自动脚本使用时，Git 已经不只是版本历史，也是工作状态的索引。所谓“清理”，不应该追求分支列表看起来最短，而应该追求每一次删除都有证据，而且出了问题还能找到回去的路。

我现在更喜欢把分支删除理解成一次小型迁移：先确认数据已经进入目标状态，再留下恢复点，最后移除旧入口。这样做的好处是，自动化工具也可以遵循同一套规则，而不是把“旧”误判成“无用”。