git branch --merged 默认只查当前分支的合并情况，易漏掉已合并进 main/develop 的分支；需显式指定基准如 --merged main，并注意 squash 合并不被识别，须手动验证后安全删除。
合并分支后不清理，很快就会堆积出一堆 feature/xxx、fix/yyy 分支，git branch 输出一屏都翻不完，连当前在哪都不好找。清理不是可选项，是每次合并后必须做的动作。
git branch --merged 为什么有时漏掉已合并分支
默认情况下，git branch --merged 只显示已合并到 当前分支 的分支。如果你刚在 feature/login 上执行了 git merge main，然后立刻运行该命令，它列出的是“已合并进 feature/login”的分支——而不是你关心的“哪些分支已合并进 main”。
- 正确做法：先
git checkout main（或git switch main），再运行git branch --merged - 如果主分支叫
develop，就得用git branch --merged develop - 注意 squash 合并：这种合并不会留下合并提交，
--merged无法识别，需额外处理（见下一条）
如何安全删除已合并分支（含 squash 场景）
直接 git branch -d 会拒绝删除未被合并的分支，这是保护机制；但对 squash 合并过的分支，Git 认为“没合并”，-d 会报错，而强行用 -D 又有风险。
- 先预览：运行
git branch --merged | grep -v "^\*\|main\|master\|develop"看候选列表 - 对疑似 squash 分支，手动验证是否已上线：
git merge-base main feature/xxx—— 如果输出的 commit 在main历史中存在，说明代码已包含 - 确认无误后，用
git branch -d feature/xxx（优先）；若提示“not fully merged”，且你已确认 squash 成功，再用git branch -D feature/xxx - 批量删本地分支（不含当前和主干）：
git branch --merged | grep -v "^\*\|main\|master\|develop" | xargs -r git branch -d
远程分支清理常被忽略的两步
删完本地分支，远程分支还在；更糟的是，其他协作者的本地仓库里还留着过期的远程追踪分支（origin/feature/xxx），下次 git fetch 还会拉下来。
- 删远程分支：
git push origin --delete feature/xxx（别用git push origin :feature/xxx，易输错） - 同步清理本地远程追踪分支：
git fetch --prune或简写git fetch -p—— 这步必须做，否则git branch -r仍显示已删的远程分支 - 团队内建议约定：谁推了远程分支，谁负责删；或统一在 CI 流水线末尾加
git cleanup -lr（需提前装git-toolbelt）
git-cleanup 和 git-sweep 的关键区别
两者都能批量清理，但触发逻辑不同，选错会导致误删或漏删。
-
git cleanup -l（来自git-toolbelt）：默认以main或master为基准，自动跳过保护分支；支持-s识别 squash 合并 -
git-sweep preview：默认也查master，但可通过--master=develop显式指定；--skip=release,v1.2可白名单保留分支 - 共同陷阱：都依赖
git fetch最新状态，运行前务必先git fetch origin，否则可能把刚合并但还没 fetch 到的分支当“未合并”给跳过
真正麻烦的不是命令记不住，而是清理时不敢删——因为不确定某个分支到底有没有被完整合入。与其靠人肉比对，不如在 PR 模板里强制要求填写“是否 squash 合并”，并在合并后立即执行清理命令，形成闭环。否则，三个月后你面对的就不是几十个分支，而是几百个带时间戳的谜题。
