2025 年 9 月至 2026 年 8 月，Git 活动量增长超过一倍，达到每月 473.3B 次事件。

我们正在重建 Git 基础设施，同时 GitHub 仍在正常运行，为 agent 规模的软件开发奠定基础。https://t.co/H5J2qxCqMT

为 agent 规模的开发构建 Git 基础设施

作者：Brian Celenza

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

Agentic 软件开发正在推动下一轮架构变革。当开发者与 agent 在每天接收数百万次提交的仓库中并发工作时，这些负载需要一种不同的 Git 架构。我们正在重建 GitHub 的 Git 基础设施来支撑它们。本文将探讨塑造这项工作的需求，以及背后的设计原则。

当今最高量级的负载揭示了我们正在为之构建的规模。一个典型仓库与最繁忙仓库之间的差距，比大多数人想象的要大得多。以下是 2026 年 8 月 GitHub 仓库月度活动量分布的大致情况：

每个仓库的 Git 事件数

仓库活动量在分布的最右端急剧攀升。GitHub 上最繁忙的仓库在 8 月收到了约十亿次请求。

除了这些最高量级的负载之外，GitHub 上的 Git 活动总量也在快速增长：2025 年 9 月至 2026 年 8 月间，其增长到原先的 2 倍以上，从每月 2182 亿次事件增至 4733 亿次。

仅在 9 月，开发者和 agent 就在 GitHub 上进行了 73.8 亿次提交，是一年前的五倍多。

这条曲线顶端的仓库展示了 agentic 开发在最前沿的样貌：大型工程团队运行着繁忙的 CI 流水线，同时不断壮大的 agent 舰队也在并行运作。支撑这些团队，意味着要为持续的并发读写构建 Git 基础设施，其规模是今天绝大多数仓库所达不到的。我们正在深入投资 Git 基础设施，以应对 agentic 软件开发的需求，为团队打造一个足以支撑其最雄心勃勃工作负载的基础。

为这一规模构建，意味着要应对多项架构挑战：

• 提交周转时间成为每个 agent 的瓶颈。 Agent 在紧密循环中几乎在每个操作之后都要提交或打快照。其速度受限于单次 push 完成的速度，因此人类几乎察觉不到的延迟，就成为了制约因素。

• 写入吞吐量需求正以数量级增长。 Push 同比增长 4.9 倍，从每月 6.9 亿次增至 33.5 亿次。数千个 agent 在同一个仓库中各自在自己的分支上工作，所产生的持续写入速率，最终都汇聚到我们架构中的单一点上。

• 合并操作都争夺同一个引用。 Trunk-based 开发、release train 和 merge queue 会把所有工作都汇聚到单个 ref 上，它必须承接每一次合并。GitHub 上的 Pull request 合并量已增长到一年前的近 4 倍。

• 每一次 push 都会放大成数千次读取。 例如，CI 和代码扫描每分钟会对同一个分支尖端进行数千次 clone 或 fetch，而这种扇出必须是低成本的。仅 GitHub Actions 在 9 月就运行了 32.6 亿次，是一年多前的 4 倍以上。

• 对仓库的操作必须持续保持快速。 为了保持快速，我们会持续压缩仓库数据并清理不再需要的对象。每一次新的写入都会增加这项工作的负担，且随着量级攀升，成本会不断叠加。

这就是为什么快速 clone 只能解决部分问题。读取相对容易扩展：增加缓存、增加副本，然后向更多客户端提供相同的字节。扩展读取是必要的，但这些负载需要的不止于此。写入要困难得多。每一次 push 都必须被持久化存储，并在下一个 agent 或 CI 任务基于其构建之前，以一致的方式对外可见。

现有架构如何应对新需求

现有架构多年来一直为开发者提供良好服务。每个仓库都由 Spokes 存储，它会在多台文件服务器的本地磁盘上保留完整副本，默认为五份。这些快速的本地磁盘让 Git 操作能以低延迟读取原生仓库数据，而额外的副本既提供了冗余，又将读取负载分散到各文件服务器。当一次 push 更新引用时，一个三阶段提交协议会使用 quorum 来确保 CI、Web 界面和 API 客户端看到一致的仓库状态。这套组合今天支撑着十亿个仓库。

然而，我们用于实现持久性的机制，与用于扩展性的机制是同一个。磁盘上的副本就是事实来源（source of truth），因此增加读取容量意味着增加另一份持久化副本。每个副本都要参与每一次写入，所以一次 push 的速度，取决于其副本集合中最慢的那一个。最终效果是：为了吸收读取负载而增加副本，反而会让写入变慢。

对大多数仓库而言，这种权衡效果良好。而在最高的活跃度级别上，它就变成了天花板：增加读取副本会给写入增加开销，失去一个副本会降低读取容量，而失去 quorum 则会完全停止写入。为了满足 agent 优先的需求，我们需要在不失去团队当前所依赖能力的前提下，将持久性与扩展性解耦。

为最繁忙的场景而建，让所有人受益

我们正在 GitHub 保持运行的同时重建基础设施。不存在一个维护窗口让全世界的代码停下来，也不会存在这样一个版本：我们要求人们在我们动手期间改变他们构建软件的方式。

我们正在为 GitHub 上要求最高的工作负载而构建：在严格监管要求下交付的企业、在一个构建操作系统的仓库中落地变更的团队、以及针对单一代码库运行数千个 agent 的组织。为这种规模进行工程设计，会为所有人抬高下限。审阅来自不同时区志愿者贡献的维护者，和提交自己第一个 pull request 的学生，都会获得同样更快、更健壮的新基础设施。

新架构还必须保留团队已经在使用的控制手段。维护者需要分支保护和必需的审阅，以确保未经审阅的变更永远不会到达默认分支。安全团队需要审计日志和仓库可见性，以便调查可疑的访问事件。值班工程师需要可靠的自动化以及足够的可观测性，来理解一次部署为何失败。

为了平台在为最繁忙的工作负载扩展的同时，仍能继续服务于这里的每一个人，以下是我们的指导原则：

• 在开发者已经信任的工作流之上构建。 团队依赖分支、审阅、合并和历史等工作流来规模化地构建、交付和治理软件。我们的新基础设施旨在以高得多的活动量支撑同样的工作流。

• 可靠性优先。 我们用开发者和组织所要求的可靠性，来衡量每一个决策。对平台的信心，让一个工程组织能够构建自动化、按计划交付、履行合规义务，并理解它所产出的软件。这项工作将切实提升吞吐量和规模，而这些增益将延续已有的信任基础。

• 让人类保持对代码的掌控。 如果系统没有帮助使用它的人和组织，或者不受他们控制，那就不值得构建。随着 agent 承担越来越多的工作，拥有代码的人依然可以审阅、理解并批准它。

方法

我们正在构建一个能更高效扩展的 GitHub 新架构。我们的方法围绕分布式系统的核心设计原则展开，将其应用于 agentic 软件开发的并发性与规模之上。我们的目标是：让全世界以 Git 和 GitHub 构建项目的开源社区和企业继续向前迈进，同时保留并调整其周边的功能和控制手段，以满足 agentic 时代的新需求。

最小化协调

一个接收大量 push 的仓库，必须快速地接受并发布更新。协调（Coordination）在保障正确性时很有价值，但过多的协调会限制写入吞吐量，并可能让繁忙的仓库变成瓶颈。我们现有的架构在一些并不需要的地方耦合得过于紧密，这限制了我们在读写之间扩展的能力，难以避免艰难的权衡。我们正在重新设计系统，保留 Git 语义所必需的协调，而让其他一切各自独立地进行。

• 只对真正需要达成一致的部分进行协调。 一次 push 中真正需要一致的部分，就是引用更新本身。存储底层对象、校验对象连通性以及密钥扫描，工作量要大得多，但其中大部分可以与其他写入并行进行。这会把一次 push 的关键路径缩短到需要协调的那小一步，因此其余工作不再拖慢确认（acknowledgment）。

• 把维护工作移出服务路径。 压缩（compaction）和垃圾回收（garbage collection）是仓库最繁重的工作之一，而今天它们运行在响应实时 Git 请求的同一批主机上。在新架构中，独立的 worker 直接针对持久化存储执行维护。繁忙的仓库可以在后台被持续优化，而不拖慢 push 和 fetch。

将存储与计算解耦

今天，本地磁盘上的完整仓库副本既充当持久化存储，又是回答 Git 请求的那一层。将两者分离，让我们可以独立地扩展它们。

• 无需增加持久化副本即可扩展读取。 在新架构中，读取容量来自轻量级 worker，它们通过缓存数据来响应请求。仓库的权威副本位于其下方的持久化存储层中。这样，平台可以吸收来自 CI 扇出、agent 舰队和大型 clone 的大量读取峰值，而无需给每一次 push 增加额外工作。

• 让每一层只做一件事。 权威的仓库数据存放在 Azure Blob Storage 中，它已经在 Azure 规模上提供了持久性和复制。计算层则针对最低延迟下的吞吐量进行优化。

• 更快地从故障中恢复。 当存储与计算耦合时，失去一台主机会同时降低容量和持久性，而恢复意味着重建一份完整的仓库副本。当两者分离时，失去一个计算 worker 更像是缓存未命中：替换 worker 可以立即开始响应请求，并在流量到来时从持久化存储填充其缓存。

• 让容量与需求匹配。 计算 worker 可以随流量变化而增减，而不是预先为峰值负载进行配置。一个正经历活动爆发的仓库——例如一次 release，或一支新 agent 舰队上线——可以在爆发期间获得额外容量，一旦爆发过去，这些容量就会撤走。

这些原则共同让我们能够支撑更高的吞吐量和更多并发工作，而不牺牲用户所需的可靠性与控制。

下一步

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

随着自动化开发提高软件变更的频率与并发性，GitHub 将在不牺牲团队所依赖的治理与控制的前提下，演进其基础。我们已经在铺设这一基础。在本系列的下一篇文章中，我们将深入探讨我们的未来架构，以及通向它的历程。