git branch --no-merged 列出最新提交不可达于当前分支（默认head）或指定提交的分支，仅反映拓扑可达性而非合并必要性，需配合--merged、git log或图形工具综合判断。
git branch --no-merged 是什么行为
git branch --no-merged 不是“查找待合并分支”的万能过滤器，它只回答一个问题：哪些分支的**最新提交**不在当前 HEAD（默认）或指定提交的可达路径上。换句话说，它列出的是「还没被当前分支吸收掉」的分支——但这个“没被吸收”不等于“需要合并”，更不等于“应该合并”。
常见误解是把它当成功能性检查工具，比如认为输出的分支都该马上 git merge。实际上，它可能包含已废弃、正在重写、或故意隔离的实验分支。
--no-merged 默认对比 HEAD，但必须明确指定目标提交
如果不加参数，git branch --no-merged 等价于 git branch --no-merged HEAD，即检查哪些分支的 tip 提交无法从当前分支顶端到达。但很多场景下你真正关心的是“哪些分支还没合并进 main”或“还没合入 release/v2.5”，这时必须显式指定：
-
git branch --no-merged main—— 查未合入 main 的分支 -
git branch --no-merged origin/main—— 查未合入远程 main 的分支（需先git fetch） -
git branch --no-merged 1a2b3c4—— 查未合入某次特定提交的分支
漏掉目标提交参数，结果就只反映当前工作分支的状态，容易误导判断。
为什么 --no-merged 有时为空，但其实还有未合并分支
这是最常踩的坑：--no-merged 只检测「分支 tip 是否可从目标提交抵达」，它不关心中间是否有部分提交已被 cherry-pick 或 rebase 过。以下情况会导致误判：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 某分支已通过
git cherry-pick把关键提交搬到了 main，但分支本身未 merge ——--no-merged main仍会列出它 - 某分支被 rebase 到 main 后方，tip 提交变了，但新 tip 不在 main 的祖先链上 —— 它会被列为
--no-merged，尽管逻辑上已同步 - 远程分支未
git fetch，origin/feature-x在本地不存在，自然不会出现在--no-merged结果里
所以不能单靠这个命令做合并决策，得配合 git log --cherry-pick --oneline main...feature-x 或图形化工具交叉验证。
搭配 --format 和 --sort 提高排查效率
原始 git branch --no-merged 输出只是分支名列表，信息量有限。加上格式化参数能快速定位关键线索：
-
git branch --no-merged main --format="%(refname:short) %(committerdate:relative) %(subject)" --sort=-committerdate—— 按提交时间倒序，带最近一条提交摘要 -
git branch --no-merged --contains 7f8a1b2—— 先确认某修复是否已在哪些分支中存在，再筛出未包含它的分支 -
git branch --no-merged -r origin/*—— 加-r查远程分支（注意需先git fetch --prune清理过期引用）
尤其要注意 --format 中的 %(refname:short) 而不是 %(branch)，后者在某些 Git 版本中不生效。
真正难的不是运行命令，而是理解它返回的每个分支背后的历史关系和协作意图。一次 --no-merged 输出可能混着紧急 hotfix、长期 feature、以及早就该删的临时分支——得手动 inspect 提交图谱才能分辨。
