git分支是动态指针而非副本，其“复杂链路”本质是多指针在提交dag上的非线性分布；需用git log --graph --all --simplify-by-decoration等组合命令还原全貌，merge-base须加--all应对多祖先，rebase会使原提交变游离但未丢失，真相在commit的parent字段。
Git 分支不是“副本”，而是一张动态指针图谱；所谓“复杂链路”，本质是多个分支指针在提交 DAG（有向无环图）上的非线性分布。
git log --graph 看不到真实拓扑？先加关键参数
默认 git log --graph 只显示当前分支的简化视图，会隐藏未被引用的提交、已合并但未删除的分支、以及被 rebase 过的提交。真正要还原图谱全貌，必须组合使用：
-
git log --graph --all --simplify-by-decoration --date=short --format="%h %ad %d %s"：强制拉取所有引用（--all），按标签/分支名折叠无关提交（--simplify-by-decoration），避免被“省略”误导 - 若发现某次提交在图中“断开”或“悬空”，大概率是它只被某个已删除分支引用过，此时需用
git fsck --unreachable检查是否残留 - 注意
--simplify-by-decoration会跳过没有分支/标签指向的提交——这不是 bug，是 Git 故意为之的“语义裁剪”，但排查 merge 基时容易误判
merge-base 找不准共同祖先？多祖先场景必须用 --all
当两个分支存在多个最近公共祖先（例如经由多次 merge 或 octopus merge 形成的“菱形结构”），git merge-base branch-A branch-B 默认只返回一个 SHA，且不保证是“最老”或“最相关”的那个。这会导致手动 rebase 或 cherry-pick 时选错基点。
- 务必改用
git merge-base --all branch-A branch-B，输出所有候选祖先，再结合git show --oneline查看各祖先的上下文 - 常见陷阱：CI 脚本里硬编码
git merge-base单值结果，遇到多祖先就 silently 选错，引发静默覆盖 - 如果输出超过两个 SHA，说明该分支图谱已进入“非单线性演化”状态，建议优先走
git merge --no-ff而非 rebase，避免历史失真
rebase 后的分支指针为何“消失”在图谱里？
执行 git rebase main feature 后，原 feature 上的提交哈希全部变更，旧提交变成 dangling commit（游离提交）。此时 git log --graph 不再显示它们，不是被删了，而是失去引用。
- 可用
git reflog feature查到 rebase 前的 HEAD 位置，再用git show <old-sha></old-sha>确认内容未丢 - 若误操作后想恢复，不要依赖
git fsck扫描——太慢且难定位；直接git branch feature-old <old-sha></old-sha>拉回旧分支更可靠 - 注意：rebase 后的分支在
--all图中仍存在，但指向全新提交链；原链仅靠 reflog 临时维系，7 天后自动 gc 清理
真正难处理的从来不是图谱本身，而是人脑对“同一逻辑功能”在不同分支上多次提交、多次变基、多次合并后的映射关系。别迷信图形工具自动连线——git cat-file -p <commit></commit> 看 parent 字段，才是唯一真相。
