每天3万次代码合并是什么概念？2026年5月，Anthropic每天合并约2500个代码变更。到了9月，这个数字变成了每天超过30000个，其中很大一部分代码由AI编写。Git成了瓶颈。于是七个人的团队造了一套新的源码控制系统Scion，用五个月把公司主仓库从Git上搬走了。
这不是小打小闹的优化。Anthropic在2026年10月公开说，他们不再用Git了。地球上几乎所有软件公司都在用Git，这家做Claude的公司说不用就不用了。
Git是怎么工作的
想象一个小应用ShopApp，三个文件：login.py、cart.py、payment.py。开发者每次改完东西存进Git，Git就记下改了什么、谁改的、什么时候改的。这条记录叫commit。一个commit接一个commit，就有了项目的完整历史，随时能回到任何一个早先的节点。
Git还有一个超能力：每个开发者的笔记本上都有一份完整拷贝，带着全部历史。你可以在火车上离线干活，准备好了再把改动推到共享副本上。这个设计让Git统治了世界，也埋下了Anthropic问题的根。
两个开发者Priya和Arun同时干活。Priya改了login.py，Arun改了payment.py，不同文件。Priya先推，Arun再推，Git说不行：先拉取。Git只检查一件事——你是不是从最新版本开始的。Arun不是，因为Priya的改动先落地了。于是Arun拉取，Git自动合并两边改动，Arun再推一次。如果两人改的是cart.py的同一行，Git猜不出谁对，标出冲突，得人来决定。对团队协作来说，这套机制运转得很好。
Anthropic到底出了什么问题
把Anthropic的规模套进去看。所有代码在一个巨型仓库里，主分支历史接近100 GB，压缩后的工作副本超过25 GB。大部分工作不是人在笔记本上做的，而是AI agent、CI任务和研究任务在永远在线的机器上跑的。每个测试都需要一份代码拷贝：每天约2500万次检出。按Git的常规方式拉取，一天流量会超过600 PB。
为了应付，他们跑了几百个内部Git镜像。但仓库长得比镜像的磁盘和内存还快，副本落后于最新代码，diff和blame这类历史操作越来越难维持。用Anthropic自己的话说，那些让Git在分布式、离线场景下表现出色的特性，正在"主动削弱我们扩展的能力"。
注意问题不在哪：Git没有在存储改动这件事上失败。它是为离线笔记本、完整拷贝的世界造的，而Anthropic的世界变成了永远在线、每天需要几百万次新鲜代码的机器。
Scion换了什么做法
核心思路：不再给每个人一份完整拷贝。服务器上留一份主拷贝，让服务器干活。
- 没有推送这回事。commit、rebase、merge都在服务器上发生。agent交上改动，服务器把它存进主代码。
- 用changeset，不用快照。每次改动只记录变了什么，历史和blame作为派生数据单独构建。
- 只取需要的部分。稀疏检出和虚拟检出让任务只拿到它用到的仓库部分。文件仍然出现在列表里，内容在被打开时才到达。
- 更少的分支。基本就是一条主线加发布分支，因为需要所有服务器达成一致的全局状态没法扩展。
真正的冲突不会消失。Anthropic说并发改动仍可能冲突，合并后和部署前的测试会抓住它们，Claude通常能修好。他们报告的结果是：CI和研究检出快了约100倍，从分钟级变成秒级；Scion基础设施的CPU和内存占用比旧的Git镜像方案小约200倍。
为什么不干脆拆成很多小仓库
好问题。Git处理小仓库很轻松，大多数公司就是这么做的。Anthropic没有解释为什么他们保留一个大仓库，但Google和Meta这类公司给出的常见理由是这样的：一个改动覆盖多个项目，如果二十个应用共用同一份登录代码，二十个仓库意味着二十次独立更新，有些应用可能好几天还在跑旧版本；共享代码只有一个版本，而不是旧版本越堆越多；所有东西在一个地方，当AI agent需要跨整个公司看代码、改代码时，这一点更重要。代价是体积，而这正是Scion要解决的问题。
你该停用Git吗
不该。Anthropic自己说Scion不是Git的通用替代品，也不会对外发布。对大多数团队来说，Git仍然是正确的工具，而且其中一些思路今天就能用上：稀疏检出、部分克隆，以及GitHub和GitLab上的合并队列。
但更值得注意的一课是：当AI agent以这种速度写代码时，连最受信任的工具都得跟着变。
热门跟贴