git branch --no-merged 主分支名可查未合入主干的功能分支，需显式指定main或master；结合git log --cherry-pick验证cherry-pick合并；CI中用git merge-base --is-ancestor预检删除操作；建议配置branch.autoSetupMerge always提升分支跟踪透明度。
git branch --no-merged 主分支名查漏网之鱼
想确认哪些功能分支还没合入主干？git branch --no-merged 是最直接的命令。它列出所有**未被当前 HEAD 所在分支完全合并**的本地分支——注意，不是“没执行过 merge”，而是“目标分支的提交历史里不包含这些分支的最新提交”。
常见误用是直接跑 git branch --no-merged 不带参数，结果查的是当前所在分支的未合并分支，容易漏掉已 checkout 过但后来切走的分支。务必显式指定主干，比如：
git branch --no-merged main
或（如果用 master）：
git branch --no-merged master
- 该命令只检查本地分支，远程分支（如
origin/feat/login）不会出现在结果中 - 如果某分支已被合并但你本地没 fetch 过最新远程状态，
--no-merged可能误报“未合并”——先git fetch再查 - 输出的分支名前面带
*表示当前所在分支，可忽略；其他都是潜在遗漏点
git log --cherry-pick --oneline 主分支名...待查分支名 判断是否真没合
git branch --no-merged 有时会“冤枉人”：某个分支的提交其实已被 cherry-pick 进主干，或通过多层 merge 间接合入，但 Git 的 DAG 合并追踪机制识别不了。这时得用 git log --cherry-pick 做精确比对。
语法是：git log --cherry-pick --oneline main...feat/user-profile（注意是三个点）。它会显示在 feat/user-profile 有、但在 main 没有的提交——前提是这些提交没被 cherry-pick 过。
- 输出为空，说明该分支所有提交都已在
main中出现（无论怎么进来的） - 只要有一行输出，就代表至少一个提交还没进主干，需人工确认是否要合
- 这个命令不依赖分支合并关系，只比提交哈希和 patch 内容，更可靠但稍慢
- 别写成两个点（
..），那只是简单范围差，无法检测 cherry-pick
CI 流水线里加 pre-merge 检查防人为疏忽
靠人每次 PR 前手动跑 git branch --no-merged 容易忘。更稳妥的方式是在 CI（比如 GitHub Actions 或 GitLab CI）里加一步预检脚本，自动拦截“还有未合并分支却试图删掉它”的操作。
典型场景：开发删自己分支前，CI 检查该分支是否已合入 main。若未合，直接失败并提示：
echo "Branch feat/api-v2 not merged into main. Refusing delete."
- 关键逻辑是：在删除分支的 workflow 中，先
git fetch origin main，再git merge-base --is-ancestor origin/main feat/api-v2 -
git merge-base --is-ancestor返回 0 表示feat/api-v2已被origin/main包含，可安全删；非 0 就得拦 - 注意必须 fetch 远程主干，否则本地
main可能滞后，导致误判 - 这个检查不能替代 code review，但能卡住明显遗漏
git config --global branch.autoSetupMerge always 避免新分支默认不跟踪
新拉的分支如果没设 upstream，git branch --no-merged main 仍能查到它，但后续 git status 或 git push 都不会提醒你“这分支还没合”，容易在忙乱中遗忘。
设全局配置让每个新分支自动关联远程对应分支：
git config --global branch.autoSetupMerge always
这样 git checkout -b feat/search 会自动尝试设置 upstream 为 origin/feat/search（如果存在），更重要的是，后续 git merge 或 git rebase 时 Git 更容易推断合并方向。
- 不设这个，
git branch -vv里新分支后面没有[origin/xxx: behind 2]这类提示，信息缺失 - 它不影响
--no-merged结果，但让分支生命周期状态更透明 - 如果团队用 fork 工作流，可能需要配合
branch.autoSetupRebase使用，避免 merge 提交污染
