博客 详情

Git不够用了？Anthropic 7人团队重造源代码控制系统，5个月完成迁移 - 欧亿体育

2005年，林纳斯·托瓦兹着手打造Git。谁曾料到，这个由他个人启动的项目，日后会成为几乎所有开发者不可或缺的版本控制工具，一用就是二十多年。

然而，如今AI编写代码的速度日益加快，Git也面临新的难题。代码能由AI在短时间内大量生成，但这些代码的存储、合并及版本管理，背后的基础设施同样需要跟上。对于代码变更量快速增长的Anthropic而言，现有的Git架构已无法满足内部开发需求。

于是，Anthropic决定自行研发。

近期，Anthropic首次在官方工程博客中披露了内部开发的版本控制系统Scion，详细叙述了团队如何在五个月内，将公司的大型代码仓库从Git迁移至Scion。

更令人惊讶的是，整个项目仅有7名工程师参与。开发过程中，他们还借助Claude重写核心架构、排查漏洞。一个只有7人的团队，究竟是怎么在五个月内完成这项大规模迁移的？

并非Git不够好，而是跟不上AI生成代码的速度

Anthropic在博客中首先解释了一个问题：为什么已经足够成熟的Git，会成为公司软件开发流程中的瓶颈？

这并不是因为Git本身出了什么问题。

Git的设计优势之一，是分布式版本控制。每个开发者都能拥有一份完整的代码仓库副本，在本地查看历史记录、比较代码差异、切换版本，即便处于离线状态，也能继续工作。对绝大多数软件项目来说，这种设计依然非常合适，也是Git能成为行业标准的重要原因。

但Anthropic的情况比较特殊。

其公司内部大量使用Claude编写代码，开发活动的规模和速度都在快速增长。

2026年5月，Anthropic每天平均合并约2500处代码变更。到了9月，这个数字已超过30000处，短短几个月增长了12倍。

此外，其主代码分支的历史记录已接近100GB，经过压缩的工作副本也超过了25 GB。

更大的压力来自持续集成（CI）。

Anthropic每天需要执行约2500万次代码检出操作，还没算上开发环境、AI Agent沙箱和研究任务产生的需求。如果每次都按传统方式获取代码仓库，理论上每天产生的Git数据传输量将超过600 PB。

为了应对这一问题，Anthropic此前已尝试了Git提供的浅克隆、稀疏检出等功能，也搭建了内部Git镜像和存放在对象存储中的仓库快照。高峰期，公司运行着数百个内部Git镜像。

这些措施确实缓解了压力，但随着每天合并的代码越来越多，维护镜像和快照也变得更加困难。快照可能逐渐落后于主分支，而在不完整的代码副本上执行代码差异比较、追踪某一行代码的修改历史等操作，也需要额外处理。

Anthropic团队随后意识到，问题可能不在于如何继续扩展现有的Git部署，而在于这套架构本身是否适合当前的工作负载。

Git的设计考虑了开发者离线工作的需求，每个客户端都能独立完成大量操作。但Anthropic的使用场景已经发生变化：大部分客户端不再是需要随时离线工作的开发者，而是始终联网的AI Agent和自动化任务。

既然这些客户端能随时访问服务器，是否还有必要让每个客户端都持有完整的代码仓库，并独立完成所有版本控制操作？

Scion就是围绕这个问题开发出来的。

Scion与Git有什么不同？

Scion并不是简单地给Git加上一个更快的服务器，而是重新设计了版本控制系统的工作方式。

在Git中，客户端能独立完成提交、查看历史记录等操作，再通过推送与其他副本交换数据。

Scion则采用了更明确的客户端与服务器分工：提交、合并、变基，以及代码历史查询等操作，都能交由服务器处理。客户端主要负责维护有限的本地缓存、管理磁盘上的工作文件，以及监控文件系统变化。需要什么数据，再向服务器请求。

这种设计带来了几个明显的区别：

首先，不再要求每个客户端都持有完整的代码仓库。

在传统Git工作流中，CI任务如果需要比较两个提交、查询某行代码的修改者，通常需要先获取仓库，或者依赖代码托管平台提供的特定接口。

Scion将这些版本控制操作通过API暴露出来。对于只需要查询代码历史、计算差异等信息的任务，可以直接向服务器发起请求，不必先检出整个仓库。

对于每天要执行数千万次代码检出的Anthropic来说，这意味着大量不必要的数据传输和本地存储工作可以省去。

其次，Scion只获取真正需要的代码。

Scion支持稀疏检出和虚拟化检出。前者只获取客户端指定目录中的文件，后者则按需加载文件内容。即使某个任务需要在磁盘上操作代码，也不必一次性获取整个仓库。

例如，某个CI任务只需要检查一个目录中的代码，就没有必要为了执行这项工作，把整个大型代码仓库都下载下来。如果任务只需要查询两个提交之间的差异，甚至可以直接调用服务器API完成，不必创建本地工作副本。

第三，Scion的各个组件可以独立扩展。

Anthropic表示，巅峰时期其运行数百个Git镜像，不仅极大消耗资源，一旦仓库超出镜像磁盘、内存上限，就再也无法扩容。

Scion的数据是分布式存储，各个组件可以独立扩缩容；即便是服务端，也不存在一份完整落地的仓库副本。没有Git打包对象包（packfile）这类概念，因此也不需要仓库维护工作。

它是如何运作的？

基于以上的设计原则，Anthropic详解了Scion的完整运作方式。

数据结构：变更记录与辅助索引分开处理

在Scion中，最基本的工作单元叫作变更集（Changeset），可以将其理解为Git提交的另一种实现方式。

不同的是，Git提交会保存一个指向文件树的引用，而Scion的变更集直接记录相对于第一个父变更集发生变化的文件列表，并通过内容寻址的方式，保存指向压缩文件内容的引用。

这种设计减少了服务器接收代码变更时需要处理的工作。Scion不需要接收Git的packfile，也不需要通过锁定或跨服务器协调来创建变更集。变更集创建完成后，就可以在整个系统中使用。

不过，仅靠变更集并不能高效回答所有问题。例如，想知道某一行代码最后由谁修改，或者一个文件经历过哪些提交，还需要额外的数据结构。

因此，Scion会根据变更集生成相应的辅助数据，包括用于代码归属追踪（Blame）、文件路径历史查询的索引，以及用于加速提交关系查询的跳表。这些数据被统称为派生数据（Derived Data），可以根据变更集及其父变更集递归计算。

这种设计还有一个好处：Scion可以根据需要增加新的索引，并自行决定何时计算和存储这些数据，而不必修改客户端。随着系统发展，团队已经为文件复制检测和按路径搜索等功能增加了新的索引。

代码检出：客户端需要什么，就获取什么

对于需要获取文件内容的场景，Scion开发了自己的客户端scn。与Git的获取协议不同，scn不会让服务器先判断客户端已经拥有多少数据，而是由客户端主动请求自己缺少的文件树和文件内容。

具体来说，客户端先从根文件树开始，逐层检查本地存储中缺少哪些文件树，再获取相应的文件内容。

由于Scion的数据对象采用内容寻址方式存储，写入后不会改变，服务器可以直接返回缓存中的对象，不必每次都重新计算客户端缺少哪些数据。

这种方式也不需要依赖一个可能达到数GB的大型packfile。文件树和文件内容可以分开获取，即使检出过程被中断，也能够继续请求尚未获取的对象。对于稀疏检出和虚拟化检出，客户端只需跳过不需要的文件树，就能减少数据获取量，无须额外设计特殊的支持机制。

分层缓存：减少重复下载和服务器负担

Scion还采用了三层缓存架构，让不同任务能够复用已经获取的数据。

第一层是运行在计算节点上的守护进程scion-daemon，负责存储和管理节点上的文件对象。同一台机器上的多个任务往往会访问相同的代码，因此可以共享这些对象，避免重复下载。

第二层是区域缓存服务器scion-cache，主要为所在区域的节点提供文件树和文件内容。缓存命中时，服务器可以直接从内存中读取数据，并以客户端能够直接使用的格式传输，不必重新计算客户端缺少哪些对象，也不需要进行Delta压缩。

如果区域缓存中没有所需数据，请求才会转发到负责提供权威数据的scion-server，由后者根据需要从Spanner或云存储中读取数据。

这三层使用相同的RPC接口，客户端不需要了解背后的缓存结构。不过，Scion会限制不同层级之间的访问关系，避免某一层发生故障后，大量请求直接涌向上游服务器，影响整个系统。

据Scion团队介绍，各层缓存的命中率均超过99%，而且不需要维护复杂的长期状态，因此可以根据需求扩容。

整体而言，根据Scion团队公布的数据，与此前的Git镜像基础设施相比，Scion对CPU和内存的需求减少到了原来的约1/200。CI和研究任务的代码检出速度也提升了两个数量级，原本需要几分钟的操作，现在可以在几秒钟内完成。其中，仅持续集成（CI）任务就节省了相当于25% CPU容量的资源。

此外，由于客户端和缓存服务器不再需要执行传统仓库的维护工作，相关任务的管理也变得更加简单。

7个人用Claude开发

Scion的开发过程，还有一个值得关注的地方：Anthropic不仅使用AI编写代码来解决开发效率问题，还借助AI加快了这套基础设施本身的开发。

按照Anthropic的介绍，一支只有7名成员的工程师团队，在五个月内完成了Scion、代码审查工具Antique，以及其他相关系统的开发和部署，并将公司的大型代码仓库完整迁移到新系统。

这项工作是在每天合并的代码量增长10倍的情况下完成的。

Anthropic表示，如果放在过去，开发并部署这样一套版本控制系统，可能需要更多工程师和数年的迭代迁移工作。Claude的代码生成能力，则让团队能够在更短的时间内完成大量开发和优化任务。

官方博文中还提到了一个具体案例。

在开发早期，团队曾经手工编写了一个用于将Git数据导入Scion的原型程序。当他们拿到内部版本的Claude Mythos Preview后，便让模型重写了整个程序。

Anthropic称，在没有额外指令的情况下，模型生成的新版本将内存消耗降低了20倍，运行速度提高了4倍，同时保留了原有程序在数据导入顺序和数据结构方面的隐含约束。

这并不意味着工程师可以完全退出开发过程。

恰恰相反，Anthropic特别提到，工程师仍然需要把控系统设计、跨组件协作和技术取舍。AI Agent有时会为了完成眼前的任务，采用违反系统约束的实现方式；有时也会针对假设性的风险加入过多验证逻辑，反而增加系统的复杂度。

Anthropic还表示，团队成员现在仍然会审查每一项变更请求，但关注点已经有所变化。相比逐行阅读所有代码，他们会更加关注修改的意图，以及这项修改是否符合系统设计。

与此同时，Claude也让团队能够投入更多精力进行测试和优化。Anthropic称，即使项目时间紧张，团队仍然为复杂的基础设施交互构建了隔离模拟环境，并加入模糊测试和更精细的速率限制机制。

Anthropic：Scion不会取代Git，也没有打算让所有人迁移

看到这里，可能有人会问：既然Scion的效率这么高，为什么不直接将它推广出去，替代Git？

Anthropic在博客中明确表示，Scion并不适合作为Git的通用替代品。

原因很现实：

Scion面向的是规模极大的单体代码仓库，主要适用于拥有数万名工程师，或者存在大量AI Agent持续生成代码的开发环境。

对于绝大多数团队来说，Git依然是合适的选择。它支持分布式开发，允许开发者在本地完成大量操作，也已经形成了成熟的工具链和开发生态。

Scion则在架构上与Git存在较大差异。企业如果希望采用这套系统，不仅需要迁移代码仓库，还需要调整代码审查、代码搜索和持续集成等配套系统。Anthropic内部使用的相关工具高度定制化，也很难直接复制到其他公司的开发环境中。

此外，Anthropic能够为内部开发投入大量计算资源，这种条件并不是所有企业都愿意承担的。

因此，Anthropic选择分享Scion的设计思路，而不是将其包装成一套适用于所有团队的通用方案。

与此同时，Anthropic还提到，未来6到12个月内，随着更多企业使用AI编程工具，类似的基础设施压力可能会逐渐出现。与其让每家公司都独立解决这些问题，不如把已经验证过的部分经验分享出来。

说到底，Anthropic开发Scion，并不是因为Git已经过时，而是因为当AI开始以远超人类的速度生成代码时，原本围绕人类开发节奏设计的工具链，也需要重新审视。

来源：https://www.anthropic.com/engineering/redesigning-source-control

本文来自微信公众号“CSDN”，整理：屠敏，36氪经授权发布。