GitHub 把 99.99999% 的仓库副本搬上 Azure：为了接住 AI 代理的读写洪流

作者：陈一帆

GitHub 工程博客称，已把平台 99.99999% 仓库的一份副本放进 Azure，剩余部分计划用「按引用的法定人数」补齐，对象存储让读取可以独立扩容。文章把这套底座定调为 agent-scale 的 Git 基础设施，但迁移时间表、口径算法与对普通用户的影响尚未公开。

GitHub 在工程博客上更新了一篇讲 Git 基础设施的文章：平台 99.99999% 的仓库已经有一份副本放在 Azure 上，剩下那一小部分会靠「按引用的法定人数」（per-reference quorums）机制补齐，配套的对象存储让读取能力可以独立扩容。文章把这套底座定调为 agent-scale 的 Git 基础设施，也就是为 AI 代理那一级的流量准备的。

先说「副本」这两个字

官方用的是 moved a copy，搬的是一份复制品，不是把仓库从原地迁走。有点像图书馆在隔壁新馆复制了一整套藏书：老馆照常开门，复制期间借书的人基本无感。所以对普通用户来说，这个动作本身不意味着地址变了或者仓库要停机。

为什么整体快照永远搬不完

Git 真正记账的单位是一个个引用——分支、标签这些指针。热门仓库每秒都在变，整库打一份快照，打完就已经落后了。按引用的法定人数，思路是把账拆小：每个引用各自凑够副本间的一致确认，这一条才算搬完，像逐条核对账本，而不是整柜封箱发货。官方说这是补齐剩余部分的办法，但摘要没说剩下的到底是哪一类仓库。

读写各走各的路

clone 和 fetch 是读，push 是写。以前两类请求挤在同一批机器上，一边来洪峰，另一边就得排队。对象存储相当于把书放进大库房，阅览室窗口想开几个开几个：读者暴增就加窗口，不必动书库本身。官方把它描述成读取可以独立扩容。对经常 clone 大仓库的人来说，这大概是整篇摘要里最值得留意的一句。不过这是架构层面的能力声明，不等于「你的 clone 明天就更快」，真实效果还得看后续实测。

为什么是现在

标题里的 agent-scale 已经点了题。AI 编码代理会批量 clone、反复拉取，节奏和人手点按钮完全是两种负载形态——这个方向从标题和摘要就能读出来。但流量到底涨了几倍、过去在哪些环节卡住，摘要没有数字，这类缺口只能等正文披露，不该替官方补算。

还没说清的部分

一是文章的准确发布日期，目前只能以原文为准；二是 99.99999% 的口径，按仓库数量算和按存储量算，结论差得很远，摘要没交代用的是哪种；三是剩余部分的迁移时间表，以及是否影响 API 行为、clone 速度和定价。这几点会直接决定「搬上云」对日常开发者的实际含义，现在都还是空白。

我自己的观察偏简单：这次最实质的变化，是把读和写从同一批资源上拆开。过去一次大规模批量拉取，容易和别人的推送互相拖累；读写分流之后，至少架构上不再互相挤兑。这属于已经宣布的能力，不是已经验证的体验。要确认它是否真的接住了代理式流量，还得看 GitHub 之后公开的数据，以及我们自己下一次拉取大仓库时的体感。

转载说明

本文根据以下公开资料整理，原文及配图出处见下方。

• [S1] The GitHub Engineering Blog