Dex Horthy 解读 Anthropic 自建版本控制系统并从 git 迁移

dex· @dexhorthy · X·2026-10-14 02:48· 2 小时前AI 评分69

AI 导读

HumanLayer 的 Dex Horthy 引用 Anthropic 工程博客：Anthropic 五个月内自建新版本控制系统并将 monorepo 完全从 git 迁移，因日合并代码变更从 5 月的约 2,500 次增至 9 月的超过 30,000 次。

正文

Anthropic 自建了自己的 git。这里最有趣的是思维方式的转变，如果你认同代码变更正越来越多地以自主方式、更快地发生*，那么这就非常说得通了：

Git 的设计初衷是让任何客户端都能提供仓库服务。完全离线，
你的*构建时*开发栈永远不会处于*运行时*部署的关键路径上。

Anthropic 的新版本控制系统（VCS）无法离线工作。有一个中心服务器，客户端必须能访问它才能运行。他们发现这样做有很多好处。

乍一听这很疯狂。如今如果 GitHub 宕机，你就无法拉取、推送或合并。想象一下，如果 GitHub 离线你就无法提交。

但在一个（某天，也许）代码每天变更 1000 次、无需人类介入的未来，你的 VCS 基本上就成了生产环境的一部分，所以不妨顺势让它保持在线，配备一个 SRE 团队等等，然后你就能为客户端带来各种有趣的性能优势，因为你可以把一些处理卸载到服务器，并重新设计哪些东西需要存储在哪里

* 我不确定自己是否认同这一点，但实验室们确实在把“不要读代码，而是利用诸如‘故障、功能请求、用户行为变化’之类的信号作为刺激来驱动智能体改变已部署代码”推为未来，所以这很吻合

这说得通吗？我们是要回到 CVS 而不是分布式吗？在 Scion 之类的东西成为主流之后 5-10 年，会不会又摆回分布式？

引用Anthropic@AnthropicAI

工程博客新文章：创建自研源代码控制系统。 5 月，我们每天合并约 2,500 项代码变更。9 月，我们每天合并超过 30,000 项。结果，我们受制于为人类（而非智能体）规模构建的开发者基础设施，成了瓶颈。在此，我们分享如何在五个月内构建一个新的版本控制系统——并将我们的 monorepo 完全从 git 迁移：https://www.anthropic.com/engineering/redesigning-source-control

在 X 查看被引用的帖子

来源：dex · x.com