Codex 把 Git 逼到极限：OpenAI 自研 Pando，推送延迟降低近 5 倍

11 月 2 日，OpenAI 工程团队发了一篇很硬的技术博客：他们没有换掉 Git，而是给 Git 重写了一个后端，叫 Pando。原因很朴素——Codex 让并行开发的数量级变了，旧的源码托管架构扛不住了。

核心看点

• 内部 monorepo 一度拉取慢、推送慢、合并失败，可靠性跌破 90%。
• Pando 保留 Git 协议与客户端兼容，工程师和 agent 的工作流一行都不用改。
• 生产环境中位推送延迟降低近 5 倍，每天承载近 1 PB 的 Git 数据。
• 核心取舍：放弃”全仓库时刻一致”，改用因果一致性；放弃”每个客户端单独打包”，改成复用 packfile。
• 评估过 3PC 与 WAL 两条常规路线，都因为”所有写操作抢同一个协调点”被否。
• 改进回馈上游，代码放在 github.com/openai/git。

问题：Codex 把提交量放大了

一个工程师同时有好几个改动等着跑 CI，每次推送又会触发多个任务去拉同一个 commit；分支更多、推送更密、合并更频繁、克隆更凶。这些需求会叠加。去年年底开始，支撑 monorepo 的系统开始掉链子：拉取和推送变慢，合并失败，可靠性一度低于 90%。

他们没有换工具，而是换后端。理由很实际：Git 二十多年积累的客户端生态、心智模型和工具链，是团队不想丢的资产；而且把后端做好，客户端侧的改进还能反哺社区。

方案：按分支并行写，按 packfile 复用读

Pando 的两个目标是：写入能横向扩展（大量并发推送到不同分支），读取能吃满带宽（大量客户端拉同一段历史）。做法是把每个分支的更新独立协调——写不同分支互不阻塞，读某个分支只需要该分支所需的历史。代价是：客户端同时看多个分支时，可能看到它们处于不同时间点。

读这一侧，Pando 不再为每个客户端单独生成 packfile，而是复用同一批 pack。客户端可能多下一点它已有的对象，但服务器可以用极小的计算把同样的字节发给成千上万个客户端。

被否掉的两条路

3PC 版本：每个副本保存完整仓库，推送要把 pack 复制到所有副本，还要多数派确认、多轮往返。读很舒服，写被副本磁盘和网络延迟拖住。

WAL 版本：pack 传到对象存储，ref 更新写进 blob 存储里的共享清单，用 compare-and-swap 原子替换。写 pack 可以并行，但只要所有推送都要更新同一份清单，瓶颈就卡在那一跳往返上；加大对象存储容量解决不了。

代价：一致性变弱了

Pando 提供的是因果一致性：推送时把 pack 作为不可变 blob 存下来，分支每移动一次就记一条 ref version，带着新 tip、来源 pack 和它依赖的旧版本。抓取时回放这些版本，重建出产生该版本的客户端所看到的状态。单个 ref 的更新是串行化的，但整个仓库没有统一时刻快照。

换来的是：只有同时推同一个 ref 的客户端才会冲突，推到不相关分支的推送不再互相排队。对以 agent 并发为主要负载的仓库来说，这笔交易划算。

总结

这篇博客表面在讲 Git，实质在讲一件事：agent 时代的软件基础设施，需要为”并发量级”重新设计。当写代码的主体从人变成”人加一群 agent”，最先崩的往往不是模型，而是那些默默假设”写操作低频、串行、由人驱动”的老系统。