Git 已不是未来，下一代 VCS 来了
What Comes After Git
我是 Steve Klabnik，来自 East River Source Control。随着 Agentic Development 的兴起，代码生成速度暴涨，Git 基于 2005 年设计的架构已难以应对如今数十亿行代码的 Monorepo 挑战。我们并不打算直接抛弃 Git，而是构建了一套全新的自定义存储引擎，它完全兼容 Git 协议，却拥有水平扩展能力。未来，开发者可以继续使用 Git 客户端，同时平滑过渡到支持 Jujutsu 等新协议的下一代版本控制系统。我们提供的是模块化基础设施，而非封闭的 Forge，让存储成为真正可靠的基石。
坦白说，我们不认为 Git 是版本控制的未来。
HN 评论区
34- rbsmith
这与其说是对文章的回应，不如说是对这里许多评论的回应，旨在提供一个视角，说明它们可能带来的价值。
我在版本控制/SCM领域及其周边工作了35年多，其中一半时间是在 BitKeeper 团队度过的。当时我的工作是思考集合、图和交织（weaves），旨在帮助团队改善商业客户的体验，同时惠及开源世界。
如果 Git 对你来说足够好，要知道这对所有人来说并非如此。对于其中一部分人来说，花钱消除这种痛苦是值得的。而消除痛苦的一部分在于能够与现有的一切保持连接，成为当前世界的足够大的超集，而不是以一种不兼容的方式变得更好。这正是我在 Steve 及其团队描绘的图景中所看到的：一个以某种方式与 Git 交互的世界，对于那些愿意付费消除痛苦的人来说，这种方式更好。
我同意，关于非 Git 存储引擎的内容确实没怎么提及。既然我有一半人生都沉浸在那个世界里，我懂：这是独门秘籍。我不指望短期内会有太多说法。
- nrr
我会呼应这里的其他评论：这篇文章在细节上非常贫乏，没有说明 ERSC 打算如何为未来改造 Git（除了将 Jujutsu 作为迁移路径），也没有说明为什么未来的格局中没有 Git（如我们所知的那种 Git）[0] 的位置。
我恰好拥有围绕这个问题的技术背景[1]，我对这次公告感到相当失望。至少提一下 pack-protocol 线格式有多让人头疼吧！让我们这些身陷 Git 业务的技术人员有点东西可以共鸣一下！
话虽如此，提到了 Fossil！\o/
--
0: 是的，他们提到了代理开发模式（agentic development patterns）以及面向 monorepo 的模式所面临的限制，但细节都被轻描淡写地略过了。特别是哪些代理开发模式让 Git 倍感压力？对于我们这些不使用代理或接触有限的用户来说，这一点并不特别明显，但这些使用模式几乎肯定反映在其他中小型公司会遇到的 Git 使用中。
1: 我甚至仔细深入地研究过是否要自己尝试重构 Git 的对象存储，使其更像是一个追加日志（append-only log），旨在缓解一些例如重度 GitOps 工作流有时会导致的问题，更不用说围绕代理开发的狂热了。就像，这个领域非常适合有人进来做得更好，但版本控制是技术人员使用的技术工具。
- EddieRingle
和其他评论一样，我很困惑这篇文章到底想做什么，除了推广一个想成为 Git 竞争对手的产品，以及又一个极度特定的“会议”。这篇文章甚至在其本该提出论点的部分，也没有提出任何实质性的论点。而且不知为何，他们还要把 GraphQL 混进来？
- asmnzxklopqw
他们试图解决什么问题？这部分对我来说仍然不太清楚。
- fergie
对我来说，Git 真正不太擅长的地方是版本化数据库，但这篇文章似乎并没有解决这个问题。事实上，我很难解析这篇文章所提出的问题和解决方案。