BitTorrent 之父想改写 Git：Bram Cohen 抛出 Manyana，版本控制终于要和“冲突地狱”算账了？

程序员世界里，有一种熟悉的挫败感，叫“我只是 pull 一下，为什么仓库炸了”。

这几乎是现代软件开发的集体记忆：两个人改了同一段代码，Git 开始吐出一坨 <<<<<<<、=======、>>>>>>>，你盯着屏幕看半天，像在破译一封来自平行宇宙的密信。版本控制本来是为了让协作变简单，结果“解决冲突”却成了很多团队里最不性感、也最消耗耐心的体力活。

现在，BitTorrent 发明人 Bram Cohen 想重新定义这件事。他最近发布了一个名为 Manyana 的项目，只有大约 470 行 Python 代码，规模不大，口气却不小：它试图给“下一代版本控制”提供一个更完整的方向，而且核心主张相当激进——合并不该失败，冲突也不该以今天这种笨拙的方式呈现。

Git 没坏，但它确实老了

先说结论：Manyana 现在还不是 Git 的替代品，更像一个概念验证。但它之所以值得看，不是因为代码量有多惊人，而是它瞄准了版本控制系统最难被撼动的一块地基。

Git 诞生于 2005 年，最初是为了支撑 Linux 内核这种超大规模协作项目。它的成功毋庸置疑：快、分布式、分支便宜、生态成熟，今天几乎是软件工业的默认底座。问题在于，Git 的很多设计决定，其实是那个时代的产物。它把“文件内容”大体看成一段段文本，把“合并”理解为基于共同祖先的三方比较。只要人和代码的协作规模还算可控，这套机制够用，甚至很好用。

可到了今天，开发环境变了。团队更分布式，代码生成工具更激进，AI agent 一次能改几百上千行，重构越来越频繁。过去那种“开发者手工小步提交”的节奏，正在被自动化和并行协作打碎。Git 当然还能工作，但越来越多时候，它像一位经验丰富却脾气古怪的老工程师：你尊重它，但也经常被它折腾。

Manyana 的切入点正是在这里。Bram Cohen 认为，版本控制早就该拥抱 CRDT 了。这个缩写全称是“无冲突复制数据类型”，它在协同编辑领域并不陌生。像多人实时编辑文档、离线修改后再同步，本质上都依赖一种理念：不管不同副本如何各自修改，系统最终都能收敛到一致结果，而且合并操作本身不会失败。

Manyana 想解决的，不是“有没有冲突”，而是“冲突怎么被看见”

这套思路最有意思的地方，不是简单喊出“以后没有冲突了”，而是重新定义什么叫冲突。

按照 Bram 的说法，基于 CRDT 的合并按定义总是成功的。也就是说，系统层面不会卡在“合并失败，请人工处理”这一步。真正需要处理的，是那些彼此“挨得太近”的改动——比如一个人删掉了整个函数，另一个人却在这个函数中间加了一行日志。传统版本控制会把左右两边的结果直接糊给你看，像两块模糊的代码尸块，让你自己脑补案发现场。

Manyana 的做法是展示“发生了什么”，而不是只展示“最后变成了什么”。谁删除了哪一段，谁又在其中插入了什么，都会被结构化地标记出来。这个区别看起来像 UI 小优化，实际上很关键。今天大部分冲突之所以烦人，不是因为程序员不懂代码，而是工具没有把上下文讲明白。它只把两个结果扔过来，让人自己推理原因。

这个视角很像法律和新闻的差别。传统冲突标记告诉你“现场现在长这样”；Manyana 试图告诉你“左边做了什么，右边又做了什么”。对于人类来说，理解动作比理解残骸容易得多。

这件事的重要性，在 AI 编程时代会被进一步放大。人类写代码时，改动通常带着连续性，自己还记得动了什么；但如果一个 agent 连续跑了几个小时，做了大范围重写，你再回头看合并冲突，靠传统 diff 去恢复上下文，几乎像法医拼图。Manyana 这种“行为级”冲突呈现，也许才是未来更适合机器协作和人机协作的方式。

真正大胆的地方：把历史放进结构里，而不是靠 DAG 去推理

Manyana 的另一个核心主张，是把历史嵌入一种所谓的“weave”结构中。简单理解，就是文件里曾经出现过的每一行，不是彻底消失，而是连同“何时添加、何时删除”的元数据一起保存在统一结构里。这样一来，合并不需要费劲去找共同祖先，也不需要沿着提交 DAG 图层层回溯。

这听起来有点反直觉。我们已经太习惯 Git 的世界观：提交图是历史，分支是路径，合并就是在几条路径之间找共同起点，然后进行三方比对。Manyana 则像在说：别老盯着路线图了，真正的历史就长在文本结构本身里。

如果这个思路成立，它会直接冲击一些版本控制里的“祖传难题”。比如 rebase。今天很多团队一边离不开 rebase，一边又对它又爱又怕。它能把历史整理得很漂亮，但也会制造一种“虚构历史”——仿佛你的提交本来就是基于最新主分支产生的，原本真实的分叉路径被改写了。Bram 提出的想法是，在 CRDT 体系下，你可以得到类似逐个重放提交到新基线上的效果，却不必丢失完整历史，只需要在 DAG 上加一个“主祖先”标注。

这其实很有野心。因为传统三方合并一旦遇到激进 rebase、复杂分叉、多方并行编辑，确实会越来越脆弱。Manyana 的回答是：别让合并依赖 DAG 的整洁程度，历史本来就该在数据结构里自洽。

我个人认为，这是整篇设计里最值得认真对待的一点。它不只是优化冲突提示，而是在试图给版本控制换一个物理定律。

这个想法为什么现在冒头，而不是十年前？

一个朴素问题是：CRDT 又不是什么新发明，为什么版本控制到现在才有人认真拿它重做？

Bram 自己给出的答案很诚实：不是理论问题，更多是 UX 问题。CRDT 在协同编辑中已经被证明有效，但放进版本控制世界，真正棘手的不是“能不能合并”，而是“合并后的结果人类怎么看、怎么理解、怎么继续工作”。如果只是一味强调“永远不失败”，最后得到的是一堆无法解释的状态叠加，那工程师只会更崩溃。

Manyana 的价值，恰恰在于它试图补上这块长期被忽视的用户体验空白。过去十几年，版本控制领域并不是没有新尝试。Pijul 试过用 patch 理论重构历史模型，Darcs 更早就挑战过传统思路，还有不少研究型工具想摆脱 Git 的祖先驱动逻辑。但这些项目很难真正撼动 Git，不只是生态输得太惨，也因为“更先进的理论”常常没有转化成“更顺手的日常体验”。

Manyana 至少抓住了一个非常接地气的痛点：程序员讨厌冲突，尤其讨厌看不懂的冲突。如果一个新系统在这件事上真能比 Git 高出一大截，它就有了被认真讨论的资格。

当然，现实的冷水也得泼一盆。现在的 Manyana 还只是单文件级 demo，cherry-pick、本地撤销这些实际工作流中的关键能力还没实现，更别提跨仓库、权限模型、托管平台集成、二进制文件处理这些企业级问题。版本控制工具之所以更换困难，不是因为大家缺乏想象力，而是因为它深度嵌入了开发流程、CI/CD、代码审查、IDE、平台服务乃至组织文化。

一句不太夸张的话：想替代 Git，难度不亚于想重新发明电子邮件。

Manyana 可能不会取代 Git，但它很可能会影响 Git 之后的世界

所以，Manyana 会成功吗？如果“成功”的定义是两年内成为主流版本控制系统，我并不看好。工具迁移成本太高，Git 的生态护城河太深，而 Manyana 目前离“可生产使用”还有非常长的路。

但如果换一个问题——它会不会影响未来版本控制工具的设计方向？我觉得答案很可能是会。

尤其是在 AI 编程快速普及的当下，很多旧问题正在以新姿态卷土重来。过去的冲突，大多发生在两位工程师之间；未来的冲突，很可能发生在人、多个 agent、自动重构工具和持续同步系统之间。那时我们要处理的，未必只是代码文本差异，而是“谁在什么时候做了什么动作，这些动作之间哪里互相踩踏”。Manyana 的行为导向冲突视图，以及“合并永不失败、冲突只做标注”的思路，明显更适合这种高并发、机器参与度更高的开发环境。

更有趣的是，这个方向也许不一定以“新 Git 替代者”的身份出现。它可能先渗透进代码审查工具、IDE 合并界面、云端开发平台，甚至先成为 Git 上层的一种增强机制。就像很多颠覆性技术，最开始不是推翻旧系统，而是先以插件、桥接层、兼容模式的姿态悄悄长出来。

Bram Cohen 这次抛出的，不是一把已经造好的武器，更像一张摊在桌上的设计草图。它远谈不上成熟，但也确实提出了一个让人很难忽视的问题：如果今天重新发明版本控制，我们还会接受“合并失败是正常的”这件事吗？

我想，越来越多人会开始认真回答：未必。