cleanup

合并了没有，要问代码托管平台

rebase 和 squash 合并都会重写提交，所以合并之后 git 自己已经无法判断一个分支是否已经合并，git branch --merged 不会列出它。照 git 的答案删，删掉的是不该删的；照它保留，则每一个 squash 合并过的分支都会永远留着。

所以每一次删除前，它都去问平台那个 PR 的真实状态，只有平台报告 MERGED 才动手。没有 PR 的分支也不会被默认当作废弃：只有 git merge-base --is-ancestor 证明它的每一个提交都已经在基线上，才可以删，并且报告里会写明是哪一项检查放行的——「没有 PR」和「已删除」摆在一起看着很吓人。

远端会被问两次，一次问已合并、一次问开着的。这两者不是对立面：一个分支可以既有一个已合并的 PR，又有一个更新的、开着的 PR，而 GitHub 会关闭任何以被删分支为头的 PR。

先列出来，再动手

第一遍什么都不写。它打印一张表：找到的每一个分支、远端分支、worktree 和残留目录，对每一个查到了什么，以及打算怎么处理。--dry-run 到此为止。

默认跑四遍；--branches、--remote、--worktrees、--residue 可以只跑其中一项，--no-remote 保留其余三项去掉远端那一项，适用于你没有推送权限的 fork。

残留这一遍处理的是 git 不会提醒你的一类情况：git mv 只移动被跟踪的文件，__pycache__、node_modules 这类被忽略的目录会留在原地并让父目录继续存在，而 git status 依然显示干净。判断标准是这个目录下面还有没有被跟踪的文件——有就不是残留。紧挨着被跟踪文件的忽略目录是工作状态，会保留：删掉一个构建缓存的代价是重新构建一次，删掉一个 .venv 的代价是一个下午。

保留的那张表

最终报告有两张表：删了什么，和留下了什么。第二张才是要读的。里面每一行都是看起来该删、实际不该删的东西，并且写明了原因——未合并的分支、还开着 PR 的远端分支、脏的 worktree、旁边还有被跟踪文件的忽略目录。

仅仅因为需要人来决定而没动的，会作为一个问题问出来，不塞进「保留」里。最常见的是一个已合并的分支正在主仓库里被 checkout 着：这时那个 checkout 本身才是残留，但分支名往往是你当时做到哪儿的唯一记录，所以它只提议，不直接给你切走。

它不做的事

它不丢弃未提交的工作、不 reset 分支、不删除没给你看过的未跟踪文件。任何有内容的 worktree 都会保留，包括只有未跟踪文件的。本次运行所在的 worktree 无论什么状态都不删——在里面执行不了这个删除。远端被删但并没有合并的分支会保留并标记出来：那要么是废弃的工作、要么是别人的失误，本地副本一旦没了就找不回来。