git分支拓扑风险源于指针关系模糊和共同祖先不可控，需用git log --graph --all --simplify-by-decoration还原真实dag；多祖先时应改用git merge-base --all避免ci静默选错基点；rebase后原提交变为dangling commit，优先通过reflog而非fsck恢复。
分支拓扑越复杂，版本稳定性风险越高，但关键不在“分支多”，而在“指针关系模糊”和“共同祖先不可控”。
git log --graph 看不到真实拓扑？默认参数会主动隐藏关键信息
默认 git log --graph 只显示当前分支的简化视图，它会跳过：未被任何分支或标签引用的提交、已合并但分支未删的旧指针、rebase 后游离的旧提交。这不是 bug，是 Git 的语义裁剪——但它会让 merge 冲突、回滚失败、CI 构建不一致等问题变得难以溯源。
- 必须加
--all拉取所有引用（包括远程分支、stash、reflog 中残留） - 必须加
--simplify-by-decoration折叠无标签/无分支指向的中间提交，避免被“假线性”误导 - 若发现某次提交在图中“悬空”，大概率是它只被已删除分支引用过，此时用
git fsck --unreachable查是否残留，而非直接认定丢失
git merge-base 返回单个 SHA？多祖先场景下这是危险信号
当两个分支存在多个最近公共祖先（比如经由 octopus merge 或多次交叉合并形成的菱形结构），git merge-base A B 默认只输出一个 SHA，且不保证是最老、最相关或 CI 脚本预期的那个。这会导致 cherry-pick 选错基点、rebase 后历史失真、甚至静默覆盖已有修复。
- 必须改用
git merge-base --all A B，拿到全部候选祖先 - 结合
git show --oneline <sha></sha>查看各祖先上下文，手动判断哪个才是逻辑上“功能起点” - CI 脚本里硬编码
git merge-base单值结果，遇到多祖先就 silently 选错——这是生产事故高频诱因
rebase 后原提交“消失”？不是删了，是失去引用变成 dangling commit
执行 git rebase main feature 后，feature 上所有提交哈希全变，原提交变成 dangling commit。此时 git log --graph 不再显示它们，但内容没丢，只是没人指向。
- 用
git reflog feature查到 rebase 前的 HEAD 位置 - 用
git show <old-sha></old-sha>确认内容完整，可直接git branch old-feature <old-sha></old-sha>拉回 - 别依赖
git fsck扫描——慢且难定位；有 reflog 就优先用 reflog
真正影响稳定性的，从来不是图谱本身有多复杂，而是人脑无法可靠映射“同一逻辑功能”在多次 merge、rebase、cherry-pick 后散落在 DAG 中的多个位置。这种映射一旦出错，测试通过的代码可能实际覆盖了线上热修复，而你完全看不出异常。
