GitHub重构Git存储 迎接智能体开发时代

GitHub 上周在 Universe 大会上预告的新一代 Git 存储架构本周揭开面纱。11 月 5 日，GitHub 发布工程博文，详解这套内部代号 Rubicon 的存储设计：Git 对象（pack 文件）存入 Azure Blob 存储，分支引用的更新交由一个名为 Ref-CAS 的复制日志服务仲裁，让数千个智能体同时向同一个仓库推送代码成为可能。

官方公布的内部压测数据显示，新架构可以在保持极低读取延迟的同时，支持单个仓库容纳 5000 个智能体并发协作，并承受每秒高达 7200 次的代码推送。值得注意的是，这套系统是在生产环境下方“暗中”搭建的——GitHub 表示，工程团队是在服务不停机的前提下逐步完成迁移的。

动力来自智能体。GitHub 观察到，平台上如今最繁忙的仓库，单秒写入峰值也只有数十次，且多为短暂脉冲；随着越来越多的研发工作交给全天候高并发运行的 AI 智能体，这种突发将在一年内演变为常态化的持续高吞吐负载。更棘手的是读放大：每一次推送都会触发 CI 流水线、部署系统和其他智能体拉取最新代码。一个典型仓库的日请求量从 3 月的约 4400 万次涨到 5 月的约 1.81 亿次，两个月翻了四倍，此后至今仍维持指数级上升。

新架构的核心思路是“尽量少协调”。Git 对象不可变且按内容寻址，多个写入者可以同时上传而互不干扰；真正需要达成一致的只有分支引用的更新，而这是一笔很小的比较交换事务，由 Ref-CAS 以多数派方式提交，每秒可处理数万笔。原有的 Spokes 系统退居路由与调度，具体读写由一批可随时丢弃、缓存可重建的虚拟副本承担，后台另有压缩节点负责合并 pack、清理不可达对象。

团队也披露了两条走过的弯路：把写前日志放进单个 blob，写入速率卡在每秒几百次；把引用拆到多个分段 blob，写入上去了，读取却受制于最慢的分段。目前 Rubicon 已开启小范围定向内测，计划明年初扩大开放，后续还规划免 clone 的单对象读取、部分副本以及原子多文件提交接口。

架构以 Rubicon 命名——罗马共和国的卢比孔河，越过得无回头。GitHub 借此表达判断：智能体主导的开发方式已经越过了不归点，底层基础设施必须跟上。

编译自 GitHub Blog，原标题：“Inside GitHub's new Git storage architecture”