git merge-base 返回空或报错的根源只有两个：分支名拼错，或分支在本地仓库不存在（如未 fetch 远程分支）；多 sha 返回说明存在多个共同祖先，常见于复杂合并历史。
git merge-base 为什么返回空或报错
常见现象是执行 git merge-base branch1 branch2 后没输出、报错 fatal: Not a valid commit name，或者返回多个 SHA。本质原因只有两个：分支名拼错，或其中一个分支在当前仓库里根本不存在（比如远程分支没 fetch 过）。
实操建议：
- 先用
git branch -a确认分支名是否完整，远程分支要带origin/前缀，比如origin/main - 如果涉及远程分支，先运行
git fetch origin，否则merge-base看不到远端提交历史 - 遇到多返回值（比如
merge-base --all），说明存在多个共同祖先——这通常发生在有多个合并提交的复杂历史中，此时应加--fork-point或改用git merge-base --octopus判断主干分叉点
merge-base 和 diff 一起看分叉后改了什么
知道共同祖先只是第一步，真正要定位“从分叉点开始，这个分支到底改了哪些文件”，得把 merge-base 结果和 git diff 配合用。
实操建议：
- 先拿到共同祖先：
ancestor=$(git merge-base main feature) - 再对比该祖先到目标分支的差异：
git diff $ancestor..feature --name-only，这样列出的是feature分支独有的改动文件 - 注意方向：用
A..B表示“从 A 之后到 B 的所有提交引入的变更”，别写反成B..A，否则结果相反 - 如果想看代码行级差异，去掉
--name-only；但大项目慎用，容易刷屏，建议加--stat先概览
rebase 场景下 merge-base 容易误判分叉点
当你对一个已推送的分支做了 git rebase，再用 merge-base 查它和上游分支的共同祖先，结果可能指向 rebase 前的老提交——这不是 bug，是设计使然：rebase 生成了全新提交，原提交链断开，merge-base 只认“可达性”，不认逻辑关系。
实操建议：
- rebase 后想定位真实分叉点，优先用
git merge-base --fork-point upstream branch，它会结合 reflog 推测原始分叉位置 - 确保
branch的 reflog 没被清理（默认保留 90 天），否则--fork-point失效 - 若 reflog 不可用，只能人工比对：用
git log --oneline upstream...branch找出第一个不属于upstream的提交，往上翻一条就是大概率分叉点
脚本里调用 merge-base 要处理退出码和空输出
自动化脚本里直接用 $(git merge-base a b) 很危险：分支不存在时命令失败，但命令替换会静默吞掉错误；更糟的是，如果没找到共同祖先，它可能返回空字符串，后续 git diff $sha..b 就变成 git diff ..b，触发意外行为。
实操建议：
- 永远检查退出状态：
if ! ancestor=$(git merge-base a b 2>/dev/null); then echo "no common ancestor"; exit 1; fi - 再验证输出非空：
if [ -z "$ancestor" ]; then ... - 用
git cat-file -t $ancestor 2>/dev/null确保返回值真是有效 commit 对象，防止 SHA 字符串伪造 - 别省略
2>/dev/null，否则 git 错误信息会混进变量，导致难以调试
共同祖先不是 Git 里的“时间戳”或“分支属性”，它纯粹由 DAG 可达性决定。一旦历史被重写（rebase/filter-branch）、或分支长期不同步，merge-base 返回的结果就可能和你脑中的“逻辑起点”不一致——这点最容易被忽略。
