GitHub 正在重建其 Git 服务背后的存储架构，以应对这样一种开发模式：人类、CI 系统和软件代理可能同时向同一批仓库写入。该公司最新的工程文章介绍了一种设计：将持久化仓库数据迁移到 Azure Blob Storage，使读取容量可以独立扩展，并把写入协调范围从整个仓库缩小到实际需要排序的单个 Git 引用。

展示将代码仓库读取与 Git 写入协调分离的云基础设施编辑图像。

这是一项重大的基础设施变更，但不是用户可以直接开启的新功能。GitHub 将这项工作描述为平台持续在线期间进行的一次重建。根据后续文章，该公司已经把 99.99999% 的仓库副本迁移到 Azure，剩余的边缘情况则需要修改写入协议。文章还报告了内部吞吐量的提升，但没有公布足够详细的基准测试信息，因此不能把这些数字视为某个特定企业或代理集群的容量保证。

因此，对于平台团队来说，眼下的问题不是某个仓库是否会突然快 35 倍，而是如何设计自动化开发工作负载，使其不依赖于每个检查点都变成一次推送、不让所有分支共享同一个热点引用，也不让每个 CI 任务反复克隆同一份数据。

GitHub 正在改变什么

GitHub 现有的架构在公司工程系列中被称为 Spokes：它在存储节点上保存完整的仓库副本，并使用基于仲裁的协调机制处理写入。这种设计提供了持久性和一致性，但也把几类不同的工作耦合在一起。同一组大致相同的副本既参与写入持久化，又提供 Git 读取服务，还要支持压缩和垃圾回收等维护工作。

当活动量沿多个方向同时上升时，这种耦合的成本会更高。代理创建提交或检查点的频率可能远高于人类开发者。大规模代理集群可以在一个仓库中创建许多分支。每次变更后，CI 都可能从分支顶端扇出大量读取请求。随后，合并队列和发布自动化又可能把写入集中到少数几个引用上。

GitHub 的重设计遵循两个相互关联的原则：只协调必须协调的部分，并将持久化存储与处理请求的计算资源分离。

第一个原则适用于 Git push 中的引用更新。Git 仓库包含由内容标识的不可变对象，以及分支、标签指针等可变引用。需要排序的是引用更新：客户端一旦观察到某个引用的新值，后续读取就不应再返回旧值。推送周围的许多其他操作，包括对象存储、连接验证、密钥扫描和维护，都可以并行执行，或移出狭窄的确认路径。

第二个原则改变了仓库副本的使用方式。GitHub 描述了一种模型：Azure Blob Storage 作为持久化来源，由轻量级工作节点提供缓存的读取容量，而不是要求每个提供读取服务的工作节点同时也是完整的持久化副本。工作节点发生故障时，更接近于缓存或计算资源损失，而不是权威仓库副本丢失。面对读取密集型突发流量，可以增加新的工作节点，而无需自动为每次写入承担同等成本。

这套架构正在逐步引入。GitHub 的文章将虚拟副本、由存储支持的工作节点、按引用串行化以及后台维护描述为迁移的一部分，而不是一次已经完成的产品发布。

代理工作负载为何暴露了旧瓶颈

这项变化常被描述为“AI 基础设施”故事，但底层压力其实更具体：高并发软件开发会产生不同分布的 Git 操作。

人类开发者可能工作几分钟后才提交并推送一个分支。自动化代理则可能在完成单个任务后就创建检查点，运行测试、修改文件，再重复这一循环。成千上万个代理在同一代码库中工作，因而会产生大量并发写入、读取、合并尝试和状态更新。要让这件事产生影响，代理不必具备广义上的自主性。只要脚本化的编码循环连接到模型，并频繁执行仓库操作，就可能给基础设施带来同样的压力。

GitHub 表示，月度 Git 活动量已从 2025 年 9 月的 2182 亿次增长到 2026 年 8 月的 4733 亿次。公司还报告称，9 月份提交次数达到 73.8 亿次，每月推送 33.5 亿次，拉取请求合并量增长近 4 倍，当月 GitHub Actions 运行次数达到 32.6 亿次。这些数字描述的是平台整体活动，并不能准确衡量单独由代理产生的活动。它们包含传统开发者工作、CI、自动化以及客户增长。不过，这些数据仍然说明，原本面向较低并发水平设计的仓库服务为何需要重新审视。

压力并不只来自写入。代理或 CI 数量庞大的仓库，可能在每次分支更新后迎来一轮 fetch、clone、状态查询和拉取请求操作。如果读取能力与参与写入仲裁的完整副本绑定在一起，扩展读取能力就可能让写入变得更加昂贵。如果仓库需要增加许多副本来吸收读取突发流量，即使写入模式没有变化，这些副本也可能增加协调和维护工作。

这次重设计的目标，是打破这种反馈循环。读取工作节点可以根据需求扩展，而持久化仓库状态与有序的引用更新则放在独立层中。这样并不会让每种 Git 操作都变得廉价，也不会消除一致性要求；它改变的是系统将协调预算花在哪里。

按引用协调是关键设计细节

GitHub 最新说明中最有价值的技术细节，是从面向整个仓库的协调转向按引用序列化。

在仓库级锁或等效的串行写入路径下，即使两个推送更新的是互不相关的分支，也可能彼此干扰。向 feature/alice 推送时，需要等待向 feature/bob 的推送完成，因为系统以仓库作为协调更新的单位。这种方式便于推理，但吞吐量会受到最慢副本、仲裁所需网络往返次数，以及能够通过共享队列的写入数量限制。

按引用序列化可以缩小冲突范围。同一分支的更新仍然需要排序。对同一引用进行两次强制推送，不能被视为相互独立，因为最终状态取决于顺序和策略。但如果不违反 Git 的一致性规则或仓库治理要求，不同分支的更新就可以并行进行。

GitHub 表示，在公司描述的迁移场景中，新方法的内部测试显示，不同引用上的写入吞吐量大约提高了 3–4 倍，同时延迟更低。这个结果比早期架构文章中提到的“写入吞吐量最高提高 35 倍”更具体，但两者都只是内部测量。公开材料并未充分说明仓库规模、并发量、工作负载构成、基线硬件、延迟百分位数或生产环境部署情况，因此外部团队无法直接把这些数字换算成容量规划公式。

这一差异对工程规划很重要。拥有数千个相互独立、生命周期较短分支的仓库，可能会因竞争减少而受益。但如果数千个工作节点都在更新同一个共享分支、同一个发布标签或同一个合并队列，那么该引用仍然是热点。按引用协调能够限制无关操作之间的竞争，却不会让单一有序数据流无限并行。

持久化存储与读取扩展

Git 的内容寻址对象模型，为分离不可变数据与可变引用状态创造了机会。对象一旦存储并通过验证，其身份就由内容决定。仓库中会变化的部分相对较小：引用会移动，而系统必须确保客户端看到的顺序与这些移动保持一致。

GitHub 将 Azure Blob Storage 描述为仓库数据的持久层，并引入一种虚拟写入副本，将传入的写入流式传输到对象存储。只有当数据在该层持久化后，写入才会得到确认。随后，轻量级读取副本可以从对象存储预热缓存，并提供读取流量，而不必像完整持久副本那样加入同一个写入仲裁过程。

其优势并不只是“云存储更快”。对象存储与服务计算资源可以采用不同方式进行配置和恢复。当发布、CI 扇出或智能体集群带来需求时，可以增加读取工作进程。读取工作进程发生故障后，也可以替换并重新填充缓存。存储维护则可由独立工作进程执行，不必与同一批机器上的实时 fetch 和 push 直接竞争。

这也存在取舍。新建的读取工作进程可能从冷缓存开始。持久存储中的协调必须在并发更新下保持正确。有些读取比其他读取更需要新鲜的引用状态，因此仅靠后台同步可能不够。GitHub 表示，后续步骤会将更多协调移入请求路径，使副本能够获取引用状态，以及自上次追赶完成后发生变化的数据。

这意味着，架构是在转移问题，而不是消除问题。系统不再要求每个完整副本参与每项操作，而是必须管理缓存新鲜度、持久化的引用状态、恢复、压缩，以及服务与维护之间的边界。这个设计的吸引力在于，这些职责可以独立扩展；但独立性也要求明确的一致性规则和强大的可观测性。

“35 倍”这一数字需要谨慎解读

GitHub 早前的文章称，重建后的架构在内部基准测试中实现了最高 35 倍的写入吞吐量。这一数字说明了工作的方向，但并不意味着某个客户仓库一定会获得 35 倍的提升。

公开文章没有充分说明基准测试配置，无法据此确定这一数字适用于哪些场景。文章没有给出仓库大小、引用数量、并发级别、写入分布、读写比例、基准系统、延迟分布、故障条件，也没有说明基准测试是否模拟了生产流量。文章同样没有表示所有仓库都已迁移到新路径，或该测量结果代表普遍可用的服务上限。

对公司的活动统计也应保持同样谨慎。推送和提交量的快速增长表明平台承受着压力，但不能证明所有增长都由智能体造成，也不能说明 Git 操作增加后，有用软件会按比例增加。大量自动化检查点可能代表高效的并行工作、不必要的变更噪声、反复重试，或者三者的混合。

运营层面的结论很直接：不要用当前并发量乘以醒目的基准数字来规划智能体平台。应将该基准视为 GitHub 正在处理结构性瓶颈的证据，然后通过推送延迟、被拒绝或重试的推送、API 速率限制、排队时间、CI 扇出和合并耗时来测量自己的工作负载。

这对工程团队当前意味着什么

用户不需要因为这项公告而重写日常 Git 工作流。GitHub 表示，其目标是在改变提供这些能力的后端时，继续保留分支、评审、合并、历史记录、分支保护、必需评审、审计日志、仓库可见性及其他控制措施。

运行高吞吐自动化的团队仍应检查自己的工作负载设计。即使 GitHub 的迁移最终缓解了当前的大部分压力，这项检查依然有价值，因为它能减少无效工作，也让故障更容易恢复。

降低不必要的推送频率

智能体不必将每个中间检查点都推送到共享远程分支。可能的话，在任务期间保留本地检查点，然后只推送有意义的里程碑，或将变更控制在一定范围内批量推送。合适的频率取决于恢复要求，以及丢失本地工作所带来的成本；但如果每次工具调用都会触发一次远程推送，就会制造本可避免的写入流量。

对于长时间运行的任务，如果团队需要细粒度恢复，应将本地或外部检查点与分支更新分开保存。这样可以把持久化恢复需求，与其他开发者和系统必须读取的 Git 引用区分开来。

避免创建单一热点引用

数千个相互独立的分支，仍可能汇聚到同一个受保护分支、发布标签或合并队列。应找出写入频率最高的引用，以及在这些引用上发生串行等待的工作流。一个仓库可能拥有出色的整体分支并行能力，但某个共享引用仍可能成为实际瓶颈。

在能够改善排序的地方使用合并队列和受控批处理，但要监控队列等待时间和重试行为。如果队列反复重新计算或重新验证同一大批变更，压力可能会从 Git 写入转移到 CI、拉取请求 API 或测试基础设施。

让 CI 读取更加有计划

即使推送量适中，以读取为主的自动化也可能压垮仓库。在工作流允许的情况下，优先使用浅克隆或部分克隆，复用仓库缓存，避免对相同输入反复执行完整克隆；当一次发布或分支更新触发大量任务时，应将扇出分散开来。

GitHub 的仓库指南建议遵守一些运行限制，例如单次推送大小为 2 GB、每个仓库 Git 读取建议上限为每秒 15 次，以及每个仓库每分钟 6 次推送的建议速率。这些限制不能替代容量规划，也没有涵盖所有 API 或企业配置，但它们提醒我们：仓库是一个共享的服务边界。自动化客户端应把已公布的限制作为设计输入，而不是通过遭遇限流才发现它们。

避免重试行为放大事故

推送或获取失败，可能导致大规模自动化集群在同一时刻重试。应使用带抖动的指数退避，限制重试次数，区分临时传输错误和策略失败，并记录原始操作 ID 或提交范围，确保重试不会产生重复工作。

重试策略还应尊重人工审核。如果工作流正在等待受保护分支更新，盲目重试可能会在操作员调查期间持续冲击同一个引用。退避是一种可靠性控制，而不只是客户端性能调优。

在提高自动化程度的同时保留治理

GitHub 表示，新基础设施旨在保留分支保护、必要审核、审计日志和仓库可见性。组织应确认自己的代理工作流明确依赖这些控制。更快的写入路径不能替代审批规则、机密扫描、必要时的签名提交、环境保护或部署检查。

代理只应获得完成任务所需的最低仓库和环境权限。应将代码生成权限与合并权限、部署凭据和生产数据分开。如果代理可以创建分支，却不能在没有审核的情况下更新受保护的默认分支，那么平台的扩展能力就能提高吞吐量，同时不会悄然移除人工决策环节。

尚未明确的问题

GitHub 对外公开的描述中，还有几个重要问题没有答案。

公司尚未公布新架构的完整推广时间表，也没有说明有多少生产仓库由这种由存储支持的读取模型提供服务、哪些工作负载符合条件，或客户何时可以预期限制和延迟出现可观察的变化。

基准测试的说法也需要更多背景。外部读者需要了解工作负载定义、仓库规模、并发水平、p50 和 p99 延迟、失败行为，以及与现有路径的比较。缺少这些细节时，“最高可达”可以作为有用的工程信号，却不能当作规划保证。

缓存预热期间的一致性也是需要关注的领域。从对象存储恢复状态的工作进程，不能以违反 Git 预期的方式返回过时的引用值。系统还必须处理压缩、垃圾回收、写入中断、跨区域延迟以及部分故障恢复，避免维护工作成为新的服务瓶颈。

最后，代理活动与平台增长报告之间的关系，仍有一部分尚未得到测量。GitHub 的统计数据将人工开发者、传统自动化、CI 以及代理式工作流合并计算。这足以说明架构调整具有必要性，但还不足以推断每个组织都会出现相同的并发模式。

如何实际理解这项公告

GitHub 正在应对软件开发形态的真实变化：仓库操作增多，并行分支增多，自动化读取增多，共享集成点承受的压力也随之上升。公司的应对方式，是减少不必要的协调，在可能的情况下将持久化存储与服务计算分离，并让读取容量独立于写入仲裁数量。

对客户而言，近期最重要的经验是保持工作负载有序。不要让代理的中间状态演变成远程 Git 操作洪流；找出热点引用；控制 CI 的扇出；缓存重复读取；让重试保持温和。即使自动化能力不断增强，也要继续执行代码审查和部署边界。

这种架构最终或许能为 GitHub 带来大得多的余量，但已发布的基准测试并没有消除对真实工作负载进行测量的必要。对平台团队来说，真正有用的问题不是 GitHub 是否宣布了一个很大的倍数，而是团队开发循环中的哪一部分目前被串行化、这种串行化是否确有必要，以及下一轮自动化工作突发到来时会发生什么。