OpenAI 自研 Git 兼容后端 Pando，支撑 Codex 级别开发规模

过去一年，我们 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 字，完整内容请点「打开原文」。）