OpenAI 自研 Git 服务端 Pando：让代码仓库的 Push 延迟下降近 80%

当一个代码仓库承载的开发活动达到一定规模，Git 本身也可能成为工程效率的瓶颈。

OpenAI 近日公开介绍了自研 Git 服务端 Pando。根据 OpenAI 公布的数据，Pando 已经承载其 monorepo 的全部开发流量，中位 Push 延迟下降近 80%，每天交付的 Git 数据接近 1 PB。

这次改造值得关注的地方，不是 OpenAI 发明了新的 Git 协议，而是它保留了开发者熟悉的 Git 客户端和使用方式，只在服务端改变了数据组织、一致性管理和传输机制。

核心思路有两个：将一致性控制从全局收缩到分支级别，以及让 Git Push 产生的数据包能够被重复利用和缓存。

为什么 OpenAI 要重新设计 Git 服务端？

Git 原本是为分布式版本控制设计的。开发者可以在本地提交代码，再通过 Push 将变更发送到远程仓库。

但在大型 monorepo 中，情况会变得复杂。

monorepo 将多个项目、组件和依赖集中在一个代码仓库中。随着开发团队扩大，多个开发者可能同时向不同分支提交代码，仓库需要处理大量并发 Push、历史对象传输和跨分支读取。

问题在于，传统 Git 服务端的一些设计在这种规模下会产生额外开销。

例如，不同分支之间存在大量并发操作，如果服务端采用过于严格的全局一致性控制，就可能让本来互不影响的操作相互等待。

另外，Git Push 通常需要将相关对象打包成 packfile 发送给服务端。如果不同 Push 之间存在大量重复历史对象，服务端和客户端就可能反复处理相似的数据。

OpenAI 的选择不是更换 Git，而是重新设计服务端如何处理这些操作。

第一个改变：将一致性控制缩小到分支级别

Pando 的第一项关键改造，是采用按分支实现的因果一致性。

传统上，如果服务端对整个仓库实施较强的全局协调，不同分支上的操作也可能受到彼此影响。

Pando 则将一致性控制放在分支维度。

可以简单理解为：对同一个分支，系统需要保证操作之间符合因果顺序；但不同分支之间，如果不存在依赖关系，就不必为了维持全局顺序而相互等待。

例如，开发者 A 向 feature-A 分支 Push，开发者 B 同时向 feature-B 分支 Push。只要两者没有需要协调的依赖，服务端就可以并行处理，而不必让一个分支的操作等待另一个分支完成。

这类设计的价值在于减少不必要的协调，让并发操作获得更大的空间。

不过，分支级一致性并不意味着取消一致性要求。它改变的是一致性管理的范围，而不是允许同一分支上的操作随意乱序。

第二个改变：让 Push 产生的 Pack 可以重复利用

第二项改造针对 Git 数据传输。

Git 在 Push 时会将需要传输的对象组织成 packfile。对于大型仓库，如果不同 Push 包含大量相同的历史对象，就可能产生重复的数据处理和传输开销。

Pando 的做法是：将每次 Push 产生的 pack 存储为可复用的不可变对象。

不可变意味着对象写入后不再原地修改。后续请求可以直接引用已有对象，而不必重新生成和存储相同的数据。

在分发环节，Pando 使用 Git 的 packfile-uri 机制，配合 Express 缓存进行传输。

这里有两个关键点：

• Packfile URI： 客户端可以通过服务端提供的 URI 获取 packfile，而不必完全依赖传统 Push 响应中的数据传输路径。
• Express 缓存： 对已经生成的 packfile 进行缓存和分发，减少重复处理，让相同数据能够被多个请求复用。

两者结合后，Pando 不只是优化一次 Push 的处理速度，还改变了 Git 历史数据的重复传输方式。

性能提升背后，还有哪些限制？

OpenAI 公布的数字相当突出：中位 Push 延迟下降近 80%，每天交付接近 1 PB Git 数据。

但这两个数字需要分开理解。

中位 Push 延迟反映的是典型请求的耗时变化，并不代表所有请求都获得了相同比例的提升，也不能直接推导出最慢请求的延迟下降了多少。

每天接近 1 PB 的数据交付量，则反映了系统的数据分发规模，不等于每天新增了 1 PB 代码，也不意味着仓库本身有这么大。

更重要的是，Pando 并没有消除所有 Git 数据传输问题。

OpenAI 也披露了几个限制：

1. 重复分支 Push 仍可能重发主干之外的历史数据。 这说明不可变 pack 的复用并不意味着所有历史对象都能在任何分支场景下完全避免重复传输。
2. 跨分支读取没有单一时间点快照。 当多个分支并发更新时，跨分支读取不能简单理解为获得整个仓库在同一时刻的统一状态。

这些限制说明，Pando 的优化是围绕实际开发负载进行的工程取舍，而不是对 Git 所有操作场景的全面重构。

Pando 真正改变的是什么？

这项工程最值得关注的地方，是它没有要求开发者放弃现有 Git 工作方式。

开发者仍然使用标准 Git 客户端和协议，不需要因为服务端升级而全面更换开发工具。

变化发生在基础设施内部：服务端通过分支级因果一致性降低并发协调成本，通过不可变 pack 和缓存机制减少重复数据处理与分发。

这也是大型工程系统优化的一种典型思路：不一定需要改变上层使用方式，而是针对规模化运行时暴露出来的瓶颈，重新设计底层实现。

当然，Pando 的性能数字目前来自 OpenAI 自己的披露，项目没有开源，外部开发者暂时无法独立复现其完整架构和性能表现。

因此，它还不能直接成为其他团队可以照搬的 Git 服务端方案。

但它至少说明，当 monorepo 的开发规模足够大时，Git 服务端本身也值得进行专门的系统工程优化。

Pando 并没有重新发明 Git，而是重新设计了 Git 在超大规模并发开发环境中的运行方式。 对 OpenAI 而言，这种改造的意义不只是让 Push 更快，更是让代码基础设施能够跟上大规模 AI 工程开发带来的数据和并发压力。