GitHub 在 2026 年 10 月 6 日通过官方工程博客宣布，正在重建支撑全球代码托管的 Git 基础设施，原因很直接：写代码的主体变了。过去一年，智能体和开发者在 GitHub 上产生的提交、推送和合并量成倍增长，原本为人类节奏设计的存储架构，先撞上了写入瓶颈。
数字先说话：推送一年涨到每月 33.5 亿次
GitHub 给出的量级变化相当陡峭。2026 年 8 月，平台的 Git 事件量达到 4733 亿次，同比翻了一倍多；2026 年 9 月，提交量达到 73.8 亿次，是一年前的五倍以上。推送从每月 6.9 亿次涨到 33.5 亿次，同比 4.9 倍；拉取请求的合并量接近一年前的四倍；GitHub Actions 在 9 月运行了 32.6 亿次，同样是四倍以上。
智能体的工作方式放大了每一次写入。数千个智能体在同一个仓库的不同分支上并行工作，产生持续的高频写入，最终又汇聚到主干这一个点上：合并要争抢同一个引用，主干开发、发布列车和合并队列把所有工作都挤到一条必须吞下全部合并的引用上。每次推送还会扇出成成千上万次读取——CI 和代码扫描每分钟要把同一个分支尖端克隆或拉取数千次。
读好扩，写难扩：老架构的耦合点
GitHub 现在的存储层叫 Spokes：每个仓库在多台文件服务器的本地磁盘上保存完整副本，默认五份，推送更新引用时用三阶段提交协议和法定人数保证网页、API 和 CI 看到一致的状态。这套架构今天支撑着十亿级仓库。
问题在于，GitHub 的持久化机制和扩容机制是同一个：磁盘上的副本既是真相来源，又是读能力的来源。想加读容量，就要再加一份持久副本；而每份副本都要参与每一次写入，一次推送的速度被最慢的那份副本拖住。于是加副本扩读会让写更慢，丢副本会掉读容量，丢了法定人数写入直接停摆。对绝大多数仓库这个取舍成立，但在最高活跃度的仓库上，它就是天花板。
重建的方向：把持久和扩容拆开
GitHub 的新架构思路是把持久性与扩容能力分离，同时守住三条不让步的线：开发流程不变，分支、评审、合并、历史这些团队已经信任的工作方式在新基础设施上原样运行，用户不需要改变习惯；可靠性优先，所有取舍先过可靠性这一关；控制权留在人手里，分支保护、必审规则、审计日志和仓库可见性这些治理能力必须保留，智能体干得再多，代码仍由所有者评审和批准。工程方法上则强调减少协调：高频推送的仓库要能快速接受并发布更新，而不是每一步都等全局达成一致。整个重建在平台不停机的状态下进行，没有留给全世界代码的维护窗口。
这件事的意义超出了 GitHub 一家。当编程智能体的产出开始以十亿次提交计价，瓶颈就从模型能力转移到了基础设施：仓库、评审和 CI 这些为人类节奏修的路，要为机器节奏重修。站内此前介绍过 GitHub 用 219 个真实 PR 考 AI 代码审查的 ReviewBench 评测：一个测的是智能体写出的代码靠不靠谱，这次重建回答的是另一半问题——平台本身接不接得住智能体写代码的速度。对重度使用编程智能体的团队来说，接下来一两年，代码平台的写入吞吐、合并排队和审计能力，会和模型本身一样值得盯。
