OpenAI 构建 Pando，为大规模代码仓库扩展 Git

过去一年，我们 monorepo 的规模和对它的需求都以惊人的速度增长。很明显，我们需要改造源码控制系统，使其能够扩展到 Codex 所带来的并发工作水平。

我们构建了 Pando，一个面向 Git 仓库的新后端，过程中没有中断任何工程工作，也没有改变团队使用 Git 的方式。Pando 现在支撑着 OpenAI monorepo 中的所有开发工作。Pando 的设计目标是实现两个雄心勃勃的目标：第一，写入可水平扩展，针对向多个分支的并发推送进行优化。第二，最大化读取吞吐量，让客户端下载数据的速度足以完全跑满其可用网络带宽。

我们在保持与 Git 协议和客户端兼容的同时达成了这些目标，使我们的工程师和 agent 都能无缝地将 Pando 融入现有工作流。在生产环境中，Pando 将推送延迟中位数降低了近 5 倍。它现在每天交付近 1 PB 的 Git 数据。

下面，我们将介绍构建新源码控制系统的动机，以及为什么选择保持与 Git 兼容。我们会将我们的系统与扩展 Git 的常见方案进行比较，说明为什么 Pando 独具能力满足 OpenAI 的可扩展性需求。我们还会讨论下一步计划，以及我们将如何继续为 Git 做贡献，以支持 agent 规模的工作。

Codex 改变了 OpenAI 开发的规模和节奏，使工程师能够并行完成远超以往的工作。这意味着更多的分支和推送、更多的合并，以及来自开发环境、研究任务和 CI 的更多 fetch 和 clone。

这些需求会叠加。一名工程师现在可能同时有多个变更等待 CI，而每次推送都可能触发多个任务去 fetch 同一个 commit。

大约从去年年底开始，支撑我们 monorepo 的系统开始难以跟上。我们遭遇了缓慢的 fetch 和 push，以及失败的合并，可靠性有时低于 90%。是我们触及了 Git 本身的极限，还是我们服务 monorepo 的方式到了极限？Git 诞生于一个通过邮件交换内核补丁的社区。二十多年来，随着开发者构建软件的方式不断变化，他们一直在围绕 Git 调整自己的工具。当我们开始在自己的 monorepo 中感受到摩擦时，对我们来说重要的是，我们能够继续在这一工作的基础上构建。

我们看到了一条路径：保留熟悉的工作流，同时重建后端，以并行处理对不同分支的推送，并向众多读者并发提供同一份历史。以 Git 作为我们源码控制工作流的基础，意味着对客户端的改进可以惠及 OpenAI 之外。我们希望把我们这份 Git⁠（在新窗口中打开）中的改进贡献到上游，与更广泛的社区分享。

扩展源码控制系统有两个基本维度：众多写者向不同分支推送，以及众多读者 fetch 同一份历史。Pando 对两者都做了优化。

第一，Pando 独立协调对每个分支的更新。对不相关分支的更新可以并行进行，fetch 某个分支的读者会得到该修订所需的历史。代价是，查看多个分支的读者可能会看到它们处于不同的时间点。

第二，Pando 在多次 fetch 之间复用 packfile（Git 将多个对象压缩在一起的格式），而不是为每个客户端生成单独的 packfile。客户端可能会下载一些它已经拥有的对象，但服务器可以用很少的计算把相同的字节提供给众多客户端。

这些选择让我们能够跨分支扩展写入，并从缓存提供读取。为了理解它们如何协同工作，我们先从 Git 如何存储和传输历史说起。

Git 必须能够让仓库的两个部分保持同步：对象和引用。

Git 仓库将文件快照以及连接它们的历史记录为一个对象图。对象可以是 blob、tree、commit 或 tag。blob 保存单个文件的内容，tree 将名称与 blob 或其他 tree 关联，形成目录结构。commit 指向一个根 tree 和零个或多个父 commit，构成仓库的历史。

对象通过其类型和内容的哈希来标识。对象也是不可变的：记录一个已更改的文件会创建新的 blob，而未更改的文件和目录可以复用现有对象。

分支和标签是引用（“ref”），指向 commit。在分支上提交会创建一个新 commit，并更新该分支的 ref 指向它。

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