复杂Git分支网络的可视化核心在于拓扑结构可推导。工具branchyard通过解析refs与merge-base关系生成祖先可达性树，计算分支派生距离。健康度需结合静默时长、合并状态及CI/PR关联判断。GitKraken侧重操作界面，branchyard专注诊断视图，仅依赖本地数据库，适合审计。
# Git复杂分支网络：可视化工具到底在解决什么问题？
分支一多，Git的可视化就成了一场灾难。这几乎是每个经历过大型项目协作的工程师都会吐槽的话题。
先说几个核心判断：真正的挑战不在于“画得不够多”，而在于“结构是否可推导”。比如，当你面对一个拥有20多个分支、频繁合并和变基的仓库时，你真正需要知道的是——某条特性分支从哪儿来的，距离主干有多远，以及它最近一次提交是什么时候。这些信息，光靠一张ASCII图是解决不了的。
## git log --graph 为什么在分支多时根本看不懂
问题的根源在于：它是线性 ASCII 渲染，压根不建模分支拓扑关系。一旦分支数量超过20条，再加上各种 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），结论越可靠。
