OpenAI 为自家单体仓库自研 Git 后端 Pando，推送延迟降低近 5 倍

OpenAI 周一详细介绍了它如何为自己的 monorepo 构建一个新的 Git 后端，以支撑开发者和他们的 agent 如今产生的越来越多的提交。

这个新后端被团队称为 Pando，公司称它将 push 延迟降低了近 5 倍，目前每天在 OpenAI 处理接近 1 PB 的 Git 数据。

OpenAI 显然是 agentic 编程工具的早期采用者。公司表示，与 2024 年第一季度相比，到今年年底，其 monorepo 的季度提交量将增长超过 2400%。但它面临的问题与许多其他企业以及 GitHub 等 Git 托管平台现在看到的情况类似。

随着开发节奏加快，Git 本身正在成为瓶颈。例如，GitHub 在最近的 Universe 主题演讲中花了大量时间介绍它如何改进基础设施以变得更快、更可靠，同时每月服务数十亿次 pull request。

这催生了 Entire（由前 GitHub CEO Thomas Dohmke 创立）这样的初创公司，以及 Cursor 的 Origin 等项目。与 OpenAI 的工作一样，这些都基于 Git，但其他一些，比如 Anthropic，基本上是从头开始，采用新的客户端和架构。

OpenAI 为什么留在 Git 上

OpenAI 团队明确提到，它希望保持与 Git 的兼容性。团队发现其 Git 后端的可靠性降到了 90% 以下，fetch 缓慢、merge 失败，但最终还是决定留在 Git 生态内。

正如 OpenAI 的 Aaron Friel、Taylor Blau 和 Ted Nyman 在公告中所问，团队问自己的问题是，它是否“触及了 Git 本身的极限，还是我们服务 monorepo 的方式的极限？”对 OpenAI 来说，答案是 Git 客户端和协议并不是真正的问题（尽管团队也在那里做了一些调整），问题在于传统 Git 服务器的构建方式。

“二十多年来，随着开发者构建软件的方式发生变化，他们一直在围绕 Git 调整自己的工具，”他们写道。“当我们开始在自己的 monorepo 中感到摩擦时，对我们来说重要的是，我们能够继续在这项工作的基础上构建。”

Pando 如何工作

Pando 去掉了大多数 Git 服务器视为要求的两件事。第一是让仓库中的每个分支同时保持一致状态。第二是为每个拉取代码的客户端构建自定义 packfile，即 Git 用于打包压缩对象的格式。

在 Git 中，分支只是指向最新提交的指针。移动该指针是 push 中唯一需要协调的部分。传统 Git 服务器会在整个仓库范围内对这些更新进行排序，因此当许多开发者并行工作时，向一个 agent 的分支 push 可能最终要等待另一个 agent 的分支。

另一方面，Pando 不会在整个仓库范围内协调每一次写入。相反，它单独处理每个分支。因此，对不相关分支的 push 不必相互等待。

团队承认这里有一个权衡。当客户端同时查看多个分支时，它可能会看到它们处于略微不同的时间点。然而，OpenAI 认为，在实践中，用户和 agent 只关心单个分支上更新的顺序。

当客户端 push 时，Pando 会在将传入的 packfile 流式写入 blob 存储时对其进行验证，而不将其解包到本地仓库。它会把新的分支 tip、packfile 的位置及其依赖关系记录在元数据存储中。默认情况下，Pando 只通告 trunk 分支作为 feature 分支 push 的基础。这使得每个 pack 可以被已经拥有所通告 trunk 历史的其他客户端复用。

然后，当另一个客户端 fetch 该分支时，Pando 会根据它已有的历史选择所需的已存储 pack。随后它通过 packfile-uri 返回下载链接，这是 Git 协议的一项功能，允许客户端单独下载 pack。

Pando 将写入者的 packfile 存储在 blob 存储中，并在共享键值存储中记录 ref 版本。在 fetch 时，Pando 选择读取者需要的 pack，并由 Express 提供这些 pack。图片来源：OpenAI。 一个名为 Express 的缓存服务随后从区域缓存中提供这些 pack，公司称命中率超过 99%。在标准云虚拟机上，clone 和 fetch 可以跑满 10 Gbps 网络链路。

一个繁忙的 monorepo 否则会让客户端每天下载数万个小 pack，因此后台 worker 会随着时间推移将它们合并成更大的 pack，这很像日志结构数据库压缩其数据。这也让 Pando 能够在对数时间内算出客户端需要哪些 pack。

Pando 与标准 Git 服务器对比

在标准 Git 服务器上，每次 fetch 都意味着要算出客户端缺少哪些对象，并专门为该客户端压缩一个新的 packfile。OpenAI 表示，这些 pack 生成成本高，且难以缓存。Pando 主要分发它已经拥有的字节。

在 push 之前，常规 Git 服务器还会列出它持有的每个分支，以便客户端跳过服务器已有的对象。据 OpenAI 称，在拥有数百万个分支的情况下，仅这个列表就可能超过 100 MiB。只通告 trunk 可以让它保持很小，但这意味着对同一分支的重复 push 会重新发送所有不在 trunk 上的内容。团队表示这是合理的权衡，因为其 monorepo 中 pack 的中位数仍然低于 20 KiB。

常规 Git 服务器还必须对仓库进行 repack 和垃圾回收以保持速度，这会消耗计算资源和磁盘 I/O。Pando 从不丢弃 pack。它会保留每个压缩级别的 pack，并从所有这些 pack 中提供服务。

对开发者来说，这些几乎不可见。他们继续使用标准 Git 命令，不过 OpenAI 现在向开发者机器和 ChatGPT 桌面应用内分发自己的 Git 构建。

OpenAI 用 Rust 在 10 周内构建了 Pando，由一名工程师设计核心，多个 Codex agent 团队负责实现。它于 4 月投入生产。

哪些内容回馈给开源 Git？

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）