git merge-base 是判断分支是否已合并进 main 的最轻量可靠方式：若其返回的最近共同祖先 SHA 与分支 HEAD SHA 相同，则说明已合并（含 fast-forward 和 merge commit）。
git merge-base 判断两个分支的最近共同祖先
要确认一个分支是否已合并进 main（或 master），本质是检查该分支的最新提交是否可从 main 的提交历史中“到达”。git merge-base 是最轻量、最可靠的方式：它返回两个分支的最近共同祖先提交 ID。
如果 git merge-base branch-name main 返回的提交 ID，和 branch-name 当前的 HEAD 一致，说明该分支的 tip 已被包含在 main 的历史中——即已合并（无论用的是 fast-forward 还是 merge commit）。
实操建议：
- 运行
git merge-base branch-name main，记下输出的 SHA - 再运行
git rev-parse branch-name，得到该分支当前 HEAD 的 SHA - 若两者完全相同，则分支已合并；否则未合并
- 注意：不要依赖
git log main..branch-name是否为空来判断——它只对 fast-forward 合并有效，merge commit 场景下会漏判
git branch --contains 检查提交是否存在于目标分支
这是更直观的验证方式：git branch --contains <commit> 列出所有包含指定提交的本地分支。常用于反向验证：取待测分支的 HEAD，看 main 是否在结果中。
实操建议：
- 执行
git branch --contains branch-name | grep 'main\|master'（Linux/macOS）或git branch --contains branch-name | findstr "main master"（Windows） - 如果输出中出现
main或master，说明该分支已合并 - 该命令会扫描所有本地分支，不含远程分支；如需检查远程，先
git fetch，再加-r参数：git branch -r --contains branch-name - 性能上比
merge-base稍慢，尤其分支多时，但语义更清晰
git log --cherry-pick 识别“逻辑等价”但非直接合并的提交
当团队使用 git cherry-pick 将某个 feature 分支的提交手动复制到 main，而非走完整 merge 流程时，merge-base 和 --contains 都会误报“未合并”。这时需要检测提交内容是否已被应用。
实操建议：
- 先确保两个分支都已更新：
git fetch origin - 运行
git log --cherry-pick --oneline main...branch-name - 如果输出为空，说明
branch-name中所有提交，其补丁集（patch ID）均已存在于main中——即逻辑上已合并 - 注意：
...是三连点，表示对称差集；双点..会漏掉 merge commit 场景 - 此方法开销较大，仅在怀疑存在 cherry-pick 场景时使用
CI/CD 脚本中安全判断合并状态的写法
自动化脚本里不能依赖交互式命令或模糊输出。推荐组合 git merge-base 和 git rev-parse 做严格字符串比对，避免空格、换行、颜色干扰。
实操建议：
- 用
git merge-base --is-ancestor branch-name main（Git 2.10+）——返回 0 表示branch-name是main的祖先，即已合并 - 兼容旧 Git 版本：用
[ "$(git merge-base branch-name main)" = "$(git rev-parse branch-name)" ]，配合set -e或显式判断退出码 - 务必在脚本开头
git checkout main && git pull，确保main是最新状态 - 别忘了处理分支不存在的异常：
git show-ref --verify --quiet refs/heads/branch-name
真正容易被忽略的不是命令怎么写，而是“合并”的定义本身：是拓扑合并？内容合并？还是 CI 认为可删除的分支？不同场景要选不同的判断依据，且必须和团队的协作规范对齐。
