OpenAI也为自己构建了一个新的Git后端
内容提要
为应对单体仓库提交量激增，OpenAI自研Git后端Pando，将推送延迟降低近5倍，每日处理近1PB数据。Pando放弃全仓库分支一致性和为每个客户端定制packfile，改为按分支独立协调、复用已存储的pack，并通过缓存分发。团队用Rust在10周内完成开发，于4月上线，并将多项Git客户端修复回馈上游，但Pando本身不开源。
延伸解读
Pando 的取舍：放弃全局一致性换取推送并行
Pando 不再要求整个仓库所有分支时刻保持一致，而是按分支独立协调。传统 Git 服务器按全仓库顺序处理分支指针更新，导致并行推送互相等待；Pando 让无关分支的推送互不阻塞。代价是客户端同时查看多个分支时可能看到略微不同的时间点，但 OpenAI 认为用户和代理只关心单个分支的更新顺序，因此这一取舍在实际场景中可接受。
packfile 复用与缓存：从“每次生成”到“分发已有字节”
传统 Git 服务器每次 fetch 都要计算客户端缺失的对象并重新压缩 packfile，成本高且难以缓存。Pando 在推送时流式验证 packfile 并存储，默认只通告 trunk 分支作为基础，使 pack 可被其他已有 trunk 历史的客户端复用。Express 缓存服务以超过 99% 的命中率从区域缓存分发这些 pack，后台 worker 还会合并小 pack，类似日志结构数据库的压缩，从而在标准云虚拟机上跑满 10 Gbps 网络链路。
兼容 Git 的边界：客户端修复回馈上游，后端不开源
OpenAI 选择保留 Git 兼容性，开发者继续使用标准 Git 命令，但公司现在向开发机及 ChatGPT 桌面应用分发自己的 Git 构建。由于 Pando 重度依赖 packfile-uri，团队修复了 Git 客户端并发下载、中断清理和断点续传等问题，并增加下载追踪。部分修改已进入上游，许多仍只存在于 OpenAI 的公开仓库，Pando 后端本身不开源，公司仅表示正在研究如何与用户分享底层技术。
Q&A
OpenAI为什么要自研Git后端Pando？
因为OpenAI的开发者及其AI代理产生的提交量激增，到今年年底季度提交量相比2024年第一季度将增长超过2400%，导致Git后端可靠性降至90%以下，出现拉取缓慢和合并失败等问题，Git本身成为瓶颈。
Pando在性能上取得了什么效果？
Pando将推送延迟降低了近5倍，目前每天处理近1PB的Git数据。
Pando放弃了传统Git服务器的哪些要求？
Pando放弃了两个传统要求：一是保持仓库中所有分支同时处于一致状态；二是为每个拉取代码的客户端构建自定义packfile。
Pando如何协调分支推送以避免等待？
Pando不跨整个仓库协调每次写入，而是独立处理每个分支。因此，对不相关分支的推送不必相互等待。代价是客户端同时查看多个分支时可能看到它们处于略微不同的时间点，但OpenAI认为实际中用户和代理只关心单个分支的更新顺序。
Pando如何复用已存储的pack并分发？
推送时，Pando在将传入packfile流式写入blob存储时进行验证，不将其解包到本地仓库，并在元数据存储中记录新分支尖端、packfile位置及依赖。默认只通告trunk分支作为特性分支推送的基础，使每个pack可被已有trunk历史的客户端复用。拉取时，Pando根据客户端已有历史选择所需存储的pack，通过packfile-uri返回下载链接，再由名为Express的缓存服务从区域缓存提供，命中率超过99%。
Pando的开发过程是怎样的？是否开源？
OpenAI用Rust在10周内完成Pando开发，由一名工程师设计核心，多个Codex代理团队实现，于4月上线生产。Pando本身不开源，OpenAI表示正在研究如何与用户分享底层技术。
