Building Git infrastructure for agent-scale development

GitHub上每天有数百万开发者构建客户依赖的产品、为开源项目做贡献并推进个人项目。多年来，GitHub的架构持续演进，以支持这些工作以及依赖它的开发者和组织不断增长的需求。

代理式软件开发正在推动下一次架构变革。随着开发者和代理在每天接收数百万次提交的仓库中并行工作，这些工作负载需要不同的Git架构。我们正在重建GitHub的Git基础设施来支持它们。本文将探讨塑造这项工作的需求及其背后的设计原则。

当前最高负载的工作场景展示了我们正在构建的规模。普通仓库与最繁忙仓库之间的差距比大多数人预期的要大得多。以下是2026年8月GitHub仓库月度活动分布的粗略图示：

在分布曲线的最末端，仓库活动量急剧上升。GitHub上最繁忙的仓库在8月收到了约10亿次请求。

除了这些最高负载的工作场景，GitHub上的Git活动总量也在快速增长：从2025年9月至2026年8月，活动量增长到之前的2倍以上，从每月2182亿事件增加到4733亿事件。

仅在9月，开发者和代理就在GitHub上完成了738亿次提交，是去年同期的5倍多。

这条曲线顶端的仓库展示了代理式开发的前沿形态：大型工程团队在运行繁忙的CI流水线的同时，也在扩展日益增长的代理舰队。支持这些团队意味着要构建能够处理持续并发读写操作的Git基础设施，其规模是目前绝大多数仓库难以企及的。我们正在深度投入Git基础设施建设，以满足代理式软件开发的需求，为团队最雄心勃勃的工作负载提供坚实基础。

为实现这种规模而构建需要解决多个架构挑战：

• 每个代理的提交周转时间成为瓶颈。 处于繁忙循环中的代理几乎在每次操作后都会提交或创建检查点。其速度受限于单次推送的完成速度，导致人类几乎无法察觉的延迟反而成为限制因素。
• 写入吞吐量需求呈数量级增长。 推送量年增长率达4.9倍，从每月0.69亿次增长到3.35亿次。单个仓库中数千个代理在各自分支上的持续写入，最终在架构中汇聚到单一节点。
• 所有合并操作竞争同一个引用。 基于主干的开发模式、发布列车和合并队列机制，将所有工作流汇聚到需要处理所有合并请求的单一引用上。GitHub上的拉取请求合并量已达到去年的4倍。
• 每次推送都会引发数千次读取操作。 例如，CI和代码扫描系统每分钟会从同一分支尖端克隆或获取数千次，这种扩散式读取必须保持低成本。仅GitHub Actions一项，9月份就运行了32.6亿次，是去年同期的4倍多。
• 仓库操作必须保持高速度。 为维持速度，我们持续压缩仓库数据并清理不再需要的对象。每次新写入都会增加这项工作量，随着数据量增长，成本呈指数级上升。

这就是为什么快速克隆只能解决部分问题。读取操作相对容易扩展：增加缓存、增加副本、向更多客户端提供相同数据。扩展读取能力至关重要，但这些工作负载需要更多措施。写入操作要困难得多。每次推送都必须持久化存储并在下次代理或CI任务使用前保证一致性。

当前架构面临的新挑战

当前架构多年来为开发者提供了良好服务。每个仓库都由Spokes存储，该系统默认在5台文件服务器的本地磁盘上保存完整副本。这些高速本地磁盘使Git操作能够以低延迟读取原生仓库数据，额外副本既提供冗余，又能将读取请求分散到多台文件服务器。当推送更新引用时，三阶段提交协议通过多数决机制确保CI、网页界面和API客户端看到一致的仓库状态。这种架构目前支撑着十亿级仓库。

然而，我们用于保证持久性的机制与扩展性机制相同。磁盘上的副本是唯一真相来源，因此增加读取能力意味着添加另一个持久化副本。每个副本都参与所有写入操作，因此推送速度取决于副本集中最慢的节点。最终结果是：增加副本以吸收读取负载反而会降低写入速度。

对于大多数仓库而言，这种权衡是可行的。但在最高活跃度场景下，这会成为瓶颈：增加读取副本会增加写入开销，丢失副本会降低读取能力，丢失多数决机制则会完全停止写入。为满足代理优先的需求，我们需要在不丢失团队依赖现有功能的前提下，将持久性与扩展性分离。

为最繁忙场景而建，惠及所有用户

我们在GitHub持续运行的同时重建基础设施。全球代码流动不会因维护窗口而停止，也不会要求用户在我们工作时改变软件构建方式。

我们正在为 GitHub 上最苛刻的工作负载构建系统：一家在严格监管要求下运营的企业、一个需要跨操作系统构建仓库的团队，以及一个针对单一代码库运行数千个代理的组织。在如此规模的工程实践中，所有人的起点都得到了提升。无论是跨时区审查志愿者贡献的维护者，还是提交第一个拉取请求的学生，都能享受到更快速、更可靠的底层架构。

新架构必须保留团队当前已使用的控制机制。维护者需要分支保护和强制审核机制，以确保未经审核的更改无法进入默认分支。安全团队需要审计日志和仓库可见性来调查可疑的访问事件。值班工程师需要可靠的自动化和足够的可观测性来排查部署失败的原因。

为了让平台在服务繁忙工作负载的同时继续满足所有用户的需求，我们制定了以下指导原则：

• 基于开发者已信任的工作流程构建。团队依赖分支、审核、合并和历史记录等流程来实现大规模软件构建、交付和治理。我们的新基础设施旨在以更高的活动量支持这些相同的工作流程。
• 将可靠性置于首位。我们根据开发者和组织所需的可靠性来衡量每一个决策。对平台的信心使工程团队能够构建自动化、按计划交付、满足合规要求，并理解其生产的软件。这项工作将显著提升吞吐量和扩展性，这些改进将进一步巩固已有的信任基础。
• 保持人员对代码的控制权。如果系统无法帮助使用它的人员和组织，且不受其控制，那么它就不值得被构建。随着代理承担更多工作，代码所有者仍然可以审查、理解并批准代码。

实施方法

我们正在构建一种能更高效扩展的新 GitHub 架构。我们的方法围绕分布式系统设计的核心原则展开，应用于智能代理软件开发的并发性和扩展性场景。我们的目标是继续推动全球使用 Git 和 GitHub 构建项目的开源社区和企业向前发展，同时保留并调整其功能和控制机制，以满足智能代理时代的新需求。

最小化协调

接收大量推送的仓库必须快速接受并发布更新。当协调机制能保护正确性时其价值显著，但过多的协调会限制写入吞吐量，并可能使繁忙仓库成为瓶颈。当前架构在某些不需要耦合的环节存在紧密耦合，这限制了我们在读写扩展上不做出艰难取舍的能力。我们正在重新设计系统，在保留 Git 语义所需的协调机制的同时，让其他操作能够独立进行。

• 仅协调需要达成一致的部分。 推送操作中真正需要达成一致的是引用更新本身。存储底层对象、验证对象连接性和执行机密扫描虽然工作量更大，但大部分操作可以与其他写入操作并行执行。这将推送操作的关键路径缩短到仅需协调的小步骤，其余工作不再延迟确认过程。
• 将维护操作移出服务路径。 压缩和垃圾回收是仓库执行的最繁重任务之一，目前它们在与处理实时 Git 请求的相同主机上运行。在新架构中，独立的工作者直接针对持久化存储执行维护操作。繁忙的仓库可以在后台持续进行优化，而不会影响推送和获取操作的性能。

将存储与计算解耦

目前，本地磁盘上的完整仓库副本同时承担着持久化存储和响应 Git 请求的双重角色。将这两者分离后，我们可以独立地对它们进行扩展。

• 在不增加持久化副本的情况下扩展读取能力。 在新架构中，读取能力来自轻量级工作者，它们通过缓存数据来响应请求。仓库的权威副本存储在持久化存储层中。这样，平台可以吸收来自 CI 扇出、代理舰队和大规模克隆的读取高峰，而无需为每次推送增加额外工作。
• 让每一层只完成单一任务。 权威仓库数据存储在 Azure Blob Storage 中，该服务已经在 Azure 规模上提供了持久性和复制能力。计算层则针对最低延迟下的吞吐量进行了优化。
• 更快地从故障中恢复。 当存储与计算耦合时，丢失一个主机会导致容量和持久性的双重下降，恢复需要重建完整的仓库副本。当它们分离后，丢失一个计算工作者更类似于缓存未命中：替代工作者可以立即开始处理请求，并在流量到达时从持久化存储中填充缓存。
• 根据需求匹配容量。 计算工作者可以根据流量变化动态增减，而无需提前为峰值负载配置资源。经历活动激增（例如发布或新代理舰队上线）的仓库可以获得临时扩容能力。当激增结束，这些容量会自动消失。

这些原则共同使我们能够在不牺牲用户所需可靠性和控制能力的前提下，支持更高的吞吐量和更多的并发操作。

后续计划

我们正在构建一种架构，旨在提供最高水平的吞吐量和可靠性。读写操作可以独立扩展，系统能够优雅地从故障中恢复。在内部基准测试中，该架构实现了高达 35 倍的写入吞吐量提升，读取能力也能独立扩展以满足需求。

随着自动化开发增加软件变更的频率和并发性，GitHub 将在不牺牲团队依赖的治理和控制能力的前提下，持续改进其基础架构。我们已经在构建这一基础。在本系列的下一篇文章中，我们将深入探讨未来架构以及推动我们到达那里的技术旅程。

作者信息

Brian 是 GitHub 上负责存储和核心服务的高级软件工程师，这些服务支撑着所有仓库交互操作。

探索更多 GitHub 内容

文档

掌握 GitHub 所需的一切，尽在一处。

前往文档

GitHub

在 GitHub 上构建未来，这里是任何人从任何地方构建任何事物的平台。

立即开始构建

客户案例

了解使用 GitHub 构建产品的公司和工程团队。

了解更多

GitHub Universe 2026

10月28-29日，加入我们在旧金山或在线参加 GitHub Universe——我们的旗舰开发者大会，汇聚全球开发者、代理和代码。

立即注册