git branch --merged 列出已完全合并进当前分支的本地分支，需先切换到目标基准分支（如main）再执行；带的是当前分支，不带但出现在列表中的即为已合并分支。
git branch --merged 看哪些分支已合并到当前分支
直接运行 git branch --merged，它列出所有**已完全合并进当前所在分支**的本地分支（包括 HEAD 自身）。这是最常用、最轻量的检查方式。
常见错误是没切到目标基准分支就执行——比如你想知道 feature/login 是否已合并进 main，就得先 git checkout main，再跑命令。否则结果是相对于当前分支（比如还在 feature/login 上），意义就反了。
- 输出中带
*的是当前分支 - 不带
*但出现在列表里的，就是已合并的分支 -
git branch --merged origin/main可以指定对比远程分支（需先git fetch）
git log --cherry-pick --oneline A...B 找出两分支间独有的提交
当 git branch --merged 不够用（比如想确认某次 PR 是否真被合入，而非只 merge commit 存在），就得比对提交内容本身。git log --cherry-pick --oneline A...B 显示在 B 中有、但在 A 中没有的提交（排除仅 commit hash 不同但 patch 相同的情况）。
注意三个点：A...B 是对称差集，不是单向；--cherry-pick 防止因 rebase 或 cherry-pick 导致误判；必须确保两个分支都已本地存在（远程分支要先 git fetch）。
- 想查
feature/x是否已进main：用git log --cherry-pick --oneline main...feature/x，如果输出为空，说明feature/x的所有改动都在main里了 - 反过来
git log --cherry-pick --oneline feature/x...main输出非空，才说明main有额外提交 - 别漏掉
--oneline，否则默认输出大量冗余信息
git merge-base A B 判断是否有共同祖先（防误删）
删除分支前，有人会用 git branch --merged 确认，但这个命令对“空合并”或“fast-forward 合并后又重置”的分支可能失效。更底层的判断是看两分支是否有共同祖先：git merge-base A B 返回最近公共 commit hash，返回空则说明完全无关。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
典型误踩场景：某人做了 git merge --ff-only feature，然后又 git reset --hard HEAD~1 把 merge commit 撤了——此时 feature 在 main 的 --merged 列表里消失，但实际代码早已在 main 中。这时 git merge-base main feature 仍能返回有效 hash，说明它确实曾被合入。
- 返回非空 hash → 有继承关系，可进一步用
log确认内容是否完整 - 返回空 → 两个分支完全独立，删前务必再确认
- 该命令不依赖 merge commit，只依赖 DAG 结构，更可靠
git show-branch --all 看分支拓扑关系（适合复杂项目）
当项目分支多、合并频繁、还有多次 revert 或 multi-parent merge 时，光靠 --merged 或 merge-base 容易漏判。git show-branch --all 用字符图展示各分支提交分布，一眼看出谁在哪条线上、谁 fork 自谁、有没有悬空提交。
输出里 + 表示该分支独有的提交，* 是当前分支的提交，! 是被 revert 的提交。重点看目标分支列是否全被 * 或 + 覆盖——如果某行只有 + 在目标分支列，其他列都是空格，说明这个提交还没被其他分支吸收。
- 加
-a参数显示所有分支（含远程），不加默认只显示本地 - 配合
git show-branch main develop feature/x可聚焦对比几个关键分支 - 输出略长，但比反复切分支 + log 更省上下文切换成本
真正容易被忽略的是：合并状态不是二元的。一次 PR 可能只合入部分 commit，或合入后又被 revert，甚至合入的是旧版代码。别只信 --merged 的输出，关键分支删之前，至少用 merge-base + log --cherry-pick 过一遍。
