7个人、5个月！人工培育Git替代品

机器之心编辑部 Git，这个统治程序员 20 年的版本控制工具，竟然被 Anthropic 自己造的新系统替换了。 而完成这一切的，只有 7 名工程师和深度参与开发的 Claude。 5 个月，Anthropic 从零开发出了内部源代码控制系统 Scion、配套的代码审查工具 Antique 以及其他多个相关系统，并完成了整个单体代码仓库从 Git 到 Scion 的迁移 。 这意味着什么？几个人借助 AI，仅需要数月，就造出一套新系统，把自家内部用了多年的 Git 直接换掉了。简直太夸张了！这就不由得有人发出了「RIP GIT」的感叹。 为什么要自己造一套 Git 替代品？ 原因很简单，Anthropic 的 AI 编程规模已经大到原有开发基础设施快撑不住了。 Anthropic 给出的数据显示，今年 5 月，其平均每天合并约 2500 次代码变更。到了 9 月， 这个数字已经突破 3 万次 ，短短 4 个月增长了 12 倍以上。并且，Anthropic 预计，这种增长短期内不会放缓。代码合并的潜在需求几乎没有上限，每当解决一个瓶颈，代码产出量就会进一步增加。 在现实的倒逼下，Anthropic 开发了内部版本控制系统，并在五个月内将整个 Monorepo（单体代码仓库）从 Git 完整迁移到 Scion。 Anthropic 在最新的博客中完整介绍了整个流程。 一、不断膨胀的 Monorepo 在介绍 Scion 之前，有必要先说明 Anthropic 的工作负载有多特殊。其使用 Claude 编写软件的程度，远远超过绝大多数公司。其中，那些为人类开发规模设计的工具在哪些地方开始吃力。源代码控制只是其中一个例子。 Anthropic 预计，短期内不会有太多公司遇到同样的问题。但随着 AI 编程工具越来越普及，其他公司应该也用不了多久就会碰到类似的瓶颈。这也是我们决定分享 Scion 的设计和开发经验的原因。 Git 是一个去中心化系统。每次克隆都会得到一份完整、独立的代码仓库。即使完全离线，开发者也能计算代码差异、查看提交历史、追踪某一行代码的修改记录以及检出任意版本。对绝大多数代码仓库来说，这套设计非常合理，也是 Git 成为行业标准的重要原因。 但随着 Anthropic 的 Monorepo 不断增长，Git 的设计越来越难以满足需求。目前，仅主分支的历史数据就接近 100GB，压缩后的工作副本也超过 25GB。 仅 CI 系统每天就要执行约 2500 万次代码检出，还没有算上开发环境、Agent 沙箱和研究任务。如果每次都直接从 Git 获取所需数据，每天产生的数据传输量将超过 600PB 。 Git 当然也提供了处理部分仓库数据的功能，例如浅克隆、稀疏检出和 Promisor Remote。业界也有一些应对大型 Monorepo 的常见办法，比如搭建内部 Git 镜像，或者把代码仓库快照保存在对象存储中。 这些方法 Anthropic 全都用过。在负载最高的时候，甚至运行着几百台内部 Git 镜像服务器。这些方案确实帮助撑了一段时间。但随着代码合并量不断增长，它们也越来越难维护。两次快照刷新之间，快照与主分支最新版本的差距会越来越大。同时，要让部分克隆的仓库正常执行 diff、blame 等依赖历史信息的操作，也需要投入越来越多的维护工作。 扩展 Git 代码检出能力的典型架构。 后来，Anthropic 重新审视了自己的使用方式，发现了一个问题。和大多数公司一样，Anthropic 实际上一直把 Git 当作集中式系统使用，所有开发工作都围绕一份权威代码仓库展开。但客户端几乎都是 Agent 和自动化任务，它们本来就始终在线。Git 为分布式和离线开发提供的那些特性，反而在代码仓库不断增长时限制了系统的扩展能力。 于是，Anthropic 开始思考：如果从一开始就按照 Agent 始终在线的特点设计源代码控制系统，它应该是什么样子？ 二、面向 Agent 规模的源代码控制 随着 Agent 开始大量编写代码，软件开发中的许多传统假设正在发生变化。Anthropic 在设计 Scion 时，充分考虑了这些变化，因此在几个核心原则上采取了与 Git 不同的方案。当然，超大型 Monorepo 的源代码控制并非没有先例。Google 的 Piper 和 Meta 的 Sapling 都积累了丰富经验，Anthropic 在开发 Scion 时也参考了这些实践。 Scion 主要遵循以下设计原则。 1. 客户端始终在线。 Git 假设客户端需要离线工作，因此必须在本地保留完整的代码仓库。但 Anthropic 的客户端几乎都是 Agent 和自动化任务，所以围绕始终可访问的服务器来设计 Scion 的客户端和通信协议。客户端需要什么数据，就从服务器获取什么数据。 2. 客户端和服务器承担不同职责。 在 Git 中，每个客户端都有能力充当一台完整的 Git 服务器。Scion 则把大部分工作交给服务器，包括查询文件历史和 blame 信息、创建提交、执行合并与变基等。客户端只负责维护一个大小受限的本地对象缓存、将工作副本中的文件写入磁盘、监控文件系统变化，并提供方便用户操作的接口。客户端自身几乎不需要进行复杂计算，因此本地保存的数据也少得多。 3. 完整的源代码控制服务，可以支持更多新应用。 在 Git 中，如果 CI 任务或其他工具想查询代码仓库的信息，比如某一行代码最后是谁修改的，或者两个提交之间有什么关系，通常需要自己维护一份本地仓库。另一种办法是依赖特定服务商提供的 API，但这些 API 未必能回答所有问题。Scion 把客户端使用的所有源代码查询功能都开放为 API。这样，很多任务根本不需要本地仓库，就能直接完成查询。 Anthropic 内部的自动化二分定位和代码回滚流水线就是例子。如果没有这种低成本、可通过程序调用的源代码访问能力，这些工具很难在当前规模下运行。 4. 所有组件都必须支持横向扩展。 过去，Anthropic 最多运行过几百台 Git 镜像服务器，占用了大量计算资源。而且，一旦代码仓库的规模超过单台镜像服务器的磁盘或内存容量，继续扩展就会非常困难。 Scion 将代码仓库数据分布式存储，每个组件都可以独立扩展。整个系统中没有任何一份完整实体化的代码仓库，服务器上也没有。Scion 也没有与 Git packfile（压缩对象包）对应的机制，因此不需要执行相关的仓库维护操作。 5. 提交必须足够轻量、支持增量处理，而且不需要加锁。 在 Git 中，开发者先在本地提交代码，再通过 push 将修改共享出去。Scion 的所有提交、变基和合并操作都在服务器端完成，因此不需要 push。但这样一来，服务器就必须能够快速处理这些操作。创建提交及更新相关数据结构的成本，必须与本次代码变更的大小成正比，而不能随着整个仓库的规模增长。否则，服务器迟早会跟不上代码提交速度。 Scion 的开发流程也尽量减少对 ref 的使用。ref 是指向提交的引用，例如分支和标签，通常只保留主分支或发布分支等必要引用。因为需要所有服务器共同维护一致状态的全局数据，未来很可能成为扩展瓶