git log --graph在分支多时难懂，因其仅线性渲染ASCII图，不建模拓扑关系；branchyard则基于refs和merge-base构建“祖先可达性树”，精准反映分支派生与距离关系。
git log --graph 为什么在分支多时根本看不懂
因为它是线性 ASCII 渲染，不建模分支拓扑关系。当有 20+ 分支、频繁 merge/rebase、存在 octopus merge 时，git log --graph --all --oneline 输出会迅速变成“字符迷宫”：相同缩进层级可能属于不同父分支，箭头指向无明确语义，合并点无法区分 fast-forward 还是 true merge。
真正需要的不是“画得更多”，而是“结构可推导”。比如：feature/auth 是从 develop 派生，还是从 release/2.1 派生？它最后一次 commit 距离 main 有多少个共同祖先？这些信息 git log --graph 不提供，必须靠人眼逆向追踪。
- 避免用
--simplify-by-decoration掩盖问题——它只是删掉未打 tag 的提交，不解决拓扑混乱 - 别依赖颜色编码（如 GitKraken 的分支色块）判断活跃性——颜色只反映本地配置，不反映远程状态或 CI 状态
- 如果
git branch -r显示的远程分支名和实际 ref 不一致（比如origin/feat/login-v2已被重命名但本地缓存未更新），树状图会误判派生关系
branchyard 的树状输出到底在算什么
branchyard 不解析 commit 内容，只读取 Git 的 refs 和 merge-base 关系。它把每个分支看作一个节点，边 = “直接派生自”，权重 = 两个 ref 之间的 commit 距离（git rev-list --count ^A B）。所以它的树不是“时间树”，而是“祖先可达性树”。
这意味着：feature/payment 显示在 main 下，并不表示它 merge 过 main，只表示 main 是它的最近公共祖先（LCA）之一；如果该分支后来 rebase 到 develop，branchyard 会重新计算 LCA 并调整位置——这是它比静态图形工具更准的原因。
- 默认以
main或master为根，但可通过--root-ref指定任意 ref（比如--root-ref release/3.0）重绘子树 - 不显示已删除但 reflog 里还存在的分支——它只看当前
refs/heads/和refs/remotes/，不查 reflog - 对 shallow clone 支持有限：如果本地没 fetch 全远程分支，
branchyard -r会漏掉那些分支，且无法计算它们与本地分支的真实距离
怎么用原生命令补足 branchyard 看不到的“健康度”
branchyard 告诉你“结构”，但不告诉你“是否该删”。真正的分支健康度要叠加三类信号：
-
静默时长：用
git for-each-ref --sort=-committerdate --format="%(committerdate:iso8601) %(refname:short)" refs/heads/查最近提交时间，超过 14 天无更新的分支，大概率已废弃 -
合并状态：用
git merge-base --is-ancestor feature/foo main && echo "merged"判断是否已合入主干；注意，这只能测单向祖先关系，不能替代git branch --merged - CI/PR 关联：没有对应打开的 PR、且最近一次 push 后 CI 已失败超 72 小时的分支，即使结构上“连着 main”，也应标记为风险分支
例如，一个显示在 branchyard 树里紧贴 main 的 hotfix/db-perf，如果 git show -s --format="%cd" hotfix/db-perf 返回的是 3 个月前，而 git ls-remote origin hotfix/db-perf 返回空，说明它只存在于本地，且早已失效。
GitKraken 和 branchyard 的分工边界在哪
GitKraken 是操作界面，branchyard 是诊断视图。你在 GitKraken 里拖拽合并分支，它调用的是 git merge；你在 branchyard 里看到某分支挂在过深的子树里，说明它长期没同步上游，该提醒负责人 rebase。
- GitKraken 的“分支图”是实时渲染的快照，不保留历史拓扑变化；
branchyard可配合 cron 每小时跑一次，输出 diff，追踪分支结构漂移 - GitKraken 的“未读 PR”提示来自 GitHub API，
branchyard完全不接触 API——它只信本地 Git 数据库，适合审计场景 - 当团队强制要求所有 PR 必须 squash merge，GitKraken 的图会显示一条直线，而
branchyard仍能通过git merge-base发现该分支其实是从旧版develop派生，存在潜在冲突风险
复杂分支网络里，可视化不是为了好看，而是为了快速定位“谁在维护什么、谁落后了多少、谁该被清理”。工具链越简单，数据源越单一（只信本地 refs），结论越可靠。
