git merge-base 不能直接给出时间，它只返回两个分支最近共同祖先的 commit hash；需配合 git show -s --format="%ci" 等命令查该提交的时间戳。
git merge-base 不是“Merge-Base-Fork命令”，它是一个内置子命令，用于找出两个分支的最近共同祖先提交（即分叉起点），但**它本身不提供时间信息**——你无法直接用它“找到最早时间点”。要定位分支偏离的**时间**，得靠它配合其他命令组合使用。
为什么 git merge-base 不能直接给出时间
git merge-base A B 返回的是一个 commit hash（比如 abc1234），这个提交是 A 和 B 的最近公共祖先。但它不带时间戳输出；即使你知道这个提交，也得额外查它的提交时间。
- 常见错误：误以为
git merge-base --fork-point能返回时间——其实它只在git rebase上下文中辅助重写逻辑，且依赖 reflog，不稳定、不可靠 - 真正可靠的分叉点 =
git merge-base A B的结果，而非--fork-point - 该提交的时间 ≈ 分支实际开始偏离的时间（前提是没做过 cherry-pick 或历史重写）
怎么拿到分叉点的准确时间
分两步：先找 commit，再查时间。推荐这条单行命令：
git show -s --format="%ci" $(git merge-base main feature)
说明：
-
$(git merge-base main feature)动态获取共同祖先的 hash -
git show -s --format="%ci"以 ISO 8601 格式输出该提交的作者时间（推荐，比%ai更常用） - 若想看更易读的格式，换用
--format="%cD"（如Wed, 10 Apr 2024 15:22:33 +0800） - 注意：如果分支间有多个合并基础（如多次合并过），
merge-base默认只返回一个——通常就是你要的那个
遇到 “fatal: Not a valid object name” 怎么办
这通常意味着分支名拼错、本地没同步远程分支，或某一分支根本不存在于当前仓库中。
- 先运行
git branch -a确认分支名是否存在（尤其注意origin/xxx是远程跟踪分支，不能直接传给merge-base做参数，除非你明确想比较本地分支和远程分支） - 如果比较的是本地分支
main和远程分支origin/feature，得先git fetch确保origin/feature已更新 -
git merge-base main origin/feature是合法的，但git merge-base main feature会失败，如果feature本地分支不存在 - 别对已删除但 reflog 还在的分支强求——reflog 时间 ≠ 分叉时间，容易误导
性能与边界情况提醒
在超大仓库（如 Linux kernel）中，git merge-base 一般仍很快，但若分支历史极深或含大量合并提交，可能略慢；不过这不是瓶颈。
- 不要用
git merge-base --all试图找“所有共同祖先”——它返回多个 commit，其中最早那个未必是分叉点（Git 的 DAG 结构里，“最近共同祖先”才是语义上正确的分叉起点） - 如果你做了交互式 rebase 或
filter-branch，原始分叉点 commit 可能已被重写，此时merge-base返回的是新历史里的等价节点，时间也会变 - 时间精度仅到秒级；同秒内多个提交需结合
git log -n 5 --oneline $(git merge-base A B)手动确认上下文
真正关键的不是命令多酷，而是意识到：分叉时间 ≈ 共同祖先提交时间，而这个提交必须真实存在于当前历史中——删了分支、没 fetch、用错分支名，都会让结果失效。
