git merge-base 直接返回两个分支的最近公共祖先提交哈希，即分叉点；它通过遍历父提交链并用哈希表查找首个交点实现，结果为完整SHA-1值，适用于脚本自动化而非图形日志。
git merge-base 能直接拿到分叉点哈希
两个分支的「最近共同祖先」就是它们分叉的位置，git merge-base 就是专干这事的。它不关心谁合并了谁，只找那个最后一次共享的提交。
最常用写法：
git merge-base <branch1> <branch2>
比如 git merge-base main feature/login 会输出一串哈希，那就是两者分叉点。如果输出为空，说明其中一个分支完全包含另一个（即没有真正分叉）。
- 支持多个分支：例如
git merge-base A B C找三者共同祖先 - 加
--all参数可列出所有可能的共同祖先（在多路合并历史中偶尔有用） - 结果是完整 SHA-1 哈希，不是缩写；如需短哈希，可管道接
cut -c1-7或用git rev-parse --short
为什么不用 git log --oneline --graph
图形化日志看着直观，但无法直接提取哈希值——你得肉眼比对两条分支最早交汇的那行，容易看错，尤其当提交密集或有合并提交时。
git log 的 --merge 或 --first-parent 等选项也无法精确定位分叉点，它们是为展示路径服务的，不是为计算祖先关系设计的。
- 图形日志适合人工排查，不适合脚本调用或自动化流程
- 存在「合并提交」时，
--first-parent会跳过被合并进来的分支历史，导致你以为的“分叉点”其实是错的 - 一旦分支重写过（rebase / filter-branch），图形日志显示的交汇位置可能和真实祖先不一致
遇到 merge-base 输出多个哈希怎么办
正常情况 git merge-base A B 只返回一个哈希。如果加了 --all 才可能多行输出；但即使没加，某些复杂合并场景（如 octopus merge）也可能让默认行为返回多个。
此时说明这两个分支有多个「最近共同祖先」，Git 会任选其一返回（取决于内部遍历顺序）。这不是 bug，而是 Git 对 DAG 图中祖先定义的宽松性所致。
- 若需稳定结果，建议显式加
--fork-point（配合 reflog 使用，适用于 rebase 后的分支） - 更稳妥的做法是结合
git merge-base --is-ancestor先判断包含关系，再决定是否真需要找分叉点 - CI/CD 脚本里别假设
git merge-base总是单行输出，最好用head -n1或read安全取第一行
分叉点哈希拿回来之后能干什么
拿到哈希后最常见用途是对比差异：git diff <fork-hash>...<branch>（注意三点语法）看该分支自分叉以来的所有变更。
也有人用它生成 changelog、触发增量构建，或者校验 PR 是否基于最新基线。
- 不要用两点语法
git diff <fork> <branch>—— 它算的是「快照差」，不含合并逻辑，可能漏掉已合并但被 revert 的提交 - 哈希本身不能直接用于
git checkout，但可以传给git show或git log -1查看上下文 - 如果分支已被 force-push 过，本地的分叉点哈希可能失效，建议先
git fetch --all再运行
