通往智能体级 Git 基础设施的桥梁

GitHub 在 2026 年 10 月 21 日发布的官方说明中，将这一轮改造定义为现有架构与下一代存储架构之间的“桥梁”，核心原则是减少协调成本，并将存储与计算解耦。迁移由流量快速增长、数据中心供电能力上限以及供应链约束共同推动，并非直接重写整套 Git 基础设施。

先把数据副本迁入 Azure

2025 年 8 月，首个仓库副本进入 Azure 中部美国区域。目前，大多数仓库的五个副本中已有两个位于 Azure，Azure 承接约一半的 Git 流量。GitHub 使用偏好路由，将请求优先发往同一区域和可用区内的副本，因此流量会随着数据副本一起迁移。官方称，已有 99.99999% 的仓库同时存在于自有数据中心和 Azure；尚未迁完的正是平台中最繁忙的一批仓库，而约 25 毫秒的跨区域往返延迟是它们继续留在原架构中的关键障碍。

把写锁从仓库缩小到引用

旧架构中的 Spokes 仲裁只需多数副本确认即可提交写入，却仍会等待每个健康副本响应。仓库级锁又覆盖整个更新过程，导致最慢的健康副本同时决定写入延迟和吞吐量上限。当副本跨越约 1,000 英里抵达 Azure，单次网络往返约需 25 毫秒，而一次写入需要多次往返，接近吞吐上限的仓库因此无法承受额外延迟。

新的处理方式把仲裁范围从整个仓库缩小到单个引用。Git 的一致性要求针对每个引用分别成立，无论更新是快进、强制推送还是删除，不同引用通常都不必互相等待。于是，只有修改同一引用的操作才会排队，代理和开发者向不同分支推送时可以并发执行。GitHub 的内部测试显示，在接近真实流量的情况下，不同引用并发写入的吞吐量提高到 3 至 4 倍，同时延迟更低；不过，单次写入仍需承担跨区域网络延迟。

让读取扩展脱离写入仲裁

GitHub 表示，多数仓库的读取次数约为写入次数的 100 至 1,000 倍，但当前读写共用副本，无法独立扩展。过渡方案首先引入一个“虚拟副本”：它是完全无状态的临时计算节点，只负责把写入流式传入 Azure Blob Storage，不处理读取。作为仲裁成员，系统只有在对象存储确认数据持久化后才返回写入成功。虚拟写副本还会合并针对不同引用的并发事务，使繁忙仓库能够以一次对象存储网络往返承载多项写入。

此后，仓库可以按需增加不参与仲裁的虚拟读副本。新副本先从 Azure Blob Storage 预热缓存，再在后台将本地状态与对象存储对齐，从而独立扩展读取能力。读副本与压缩任务也能分别配置内存和计算资源，不再相互争用。

适用场景与现实限制

• 多分支、多代理并行写入的仓库，可从引用级并发中直接受益。
• 读取远多于写入的仓库，可利用独立读副本扩展缓存与计算容量。
• 需要迁移至 Azure、但暂不能一次性更换存储和计算平台的仓库，可先通过引用级仲裁跨过延迟门槛。

这套方案仍有边界。后台对账并不适合所有读取；若要覆盖全部读取类型，需要改为在线同步，并只获取副本上次追平后发生变化的引用状态和数据。写入方面，每次更新仍需等待持有完整仓库副本的仲裁成员，下一阶段还需解决持久化引用状态、压缩和垃圾回收的扩展问题。Git 对象本身不可变且按内容命名，无须为对象写入达成一致，真正需要快速排序的状态只占较小部分。官方也将这一阶段明确视为过渡桥梁，而非下一代架构的最终形态。

资料来源：The bridge to agent-scale Git infrastructure（2026-10-21）。