BitTorrent 的发明者 Bram Cohen 发布了一个新项目：Manyana。这是一个版本控制系统的原型，基于 CRDT（无冲突复制数据类型），旨在解决 Git 等当前工具的根本性问题。

Cohen 说："这个项目呈现了版本控制未来的一致愿景——以及构建它的令人信服的案例。"

Git 的困境

Git 已经统治了版本控制近 20 年。但它的设计中有几个根本性问题：

  1. 合并冲突是阻塞性的：当两个分支修改同一文件的同一部分时，Git 会失败，要求人工介入
  2. 冲突标记不具信息性：Git 显示两个代码块，你需要在脑中重建发生了什么
  3. 历史在 DAG 中而非结构中：合并需要找到共同祖先，遍历有向无环图
  4. 变基会破坏历史：传统变基创建虚构的历史，让提交看起来像是在最新主干上发生的

Manyana 试图通过 CRDT 解决这些问题。

CRDT 的核心优势

CRDT 的关键属性是：合并总是成功，结果总是相同，无论分支以什么顺序合并。

这个单一属性对版本控制的每个方面都有深远影响：

合并永不失败：CRDT 合并总是产生结果。冲突在并发编辑"太近"时会被标记以供审查，但永远不会阻塞合并本身。

行排序是永久的：当两个分支在同一位置插入代码时，CRDT 选择一个排序并固定。这防止了当冲突部分都被保留但在不同分支上以不同顺序解决时的问题。

历史在结构中：状态是一个编织——包含文件中曾经存在的每一行的单一结构，带有添加和删除的元数据。这意味着合并不需要找到共同祖先或遍历 DAG。两个状态输入，一个状态输出，总是正确。

冲突标记的改进

Cohen 展示了一个对比：

传统 VCS 的冲突标记：

<<<<<<< left
===
def calculate(x):
    a = x * 2
    logger.debug(f"a={a}")
    b = a + 1
    return b
>>>>>>> right

两个不透明的块。你需要在脑中重建发生了什么。

Manyana 的冲突标记：

<<<<<<< begin deleted left
def calculate(x):
    a = x * 2
======= begin added right
    logger.debug(f"a={a}")
======= begin deleted left
    b = a + 1
    return b
>>>>>>> end conflict

每个部分告诉你发生了什么以及谁做的。左边删除了函数。右边在中间添加了一行。你可以看到冲突的结构，而不是盯着两个块试图弄清楚。

变基不再破坏历史

Cohen 特别兴奋的一个想法是：变基不必破坏历史。

传统变基创建虚构的历史，让你的提交看起来像是在最新主干上发生的。在 CRDT 系统中，你可以获得相同的效果——逐个在新区重播放提交——同时保留完整历史。唯一需要添加的是 DAG 中的"主要祖先"注释。

这很重要，因为激进的变基很快会产生没有单一共同祖先的合并拓扑，这正是传统三路合并失效的地方。CRDT 不在乎——历史在编织中，而不是从 DAG 重构。

UX 问题已经解决

CRDT 版本控制长期被认为有微妙的 UX 问题，这就是为什么它还没有发生。Cohen 说，这个项目解决了这些问题：

  1. 合并总是成功，但冲突会被标记：系统不会失败，但会告诉你哪里需要审查
  2. 冲突呈现真正有用：算法跟踪每一边做了什么，而不仅仅是显示两个结果
  3. 历史可追溯：每一行都有元数据，你可以看到它何时被添加和删除

为什么还没有发生

如果 CRDT 这么好，为什么还没有成为主流？

部分原因是时机。CRDT 在学术界已经存在了很长时间，但直到最近，性能才足够好，可以处理大型代码库。部分原因是 UX 问题——如何呈现冲突而不让用户感到困惑。部分原因是惯性——Git 已经很强大，改变需要理由。

Cohen 认为现在时机成熟了。AI 辅助编程正在改变开发工作流，传统的版本控制工具没有为这些新工作流设计。CRDT 的"永不失败"属性对于 AI 生成的频繁、快速更改特别有价值。

实际应用

Manyana 是一个演示，不是完整的版本控制系统。它是大约 470 行 Python，操作单个文件。Cherry-picking 和局部撤销尚未实现，但 README 概述了如何实现。

但这已经足够证明 CRDT 版本控制可以处理困难的 UX 问题，并给出比我们当前使用的所有工具更好的答案。

更广泛的含义

版本控制不仅仅是工具——它是协作的基础设施。当合并总是成功，当冲突不那么令人沮丧，当历史更容易理解时，协作的摩擦就减少了。

在 AI 辅助编程的时代，代码更改的速度和频率都在增加。传统的版本控制工具可能会成为瓶颈。CRDT 提供了一种不同的方式思考版本控制——不是作为防止冲突的机制，而是作为管理冲突的机制。

结语

Cohen 说："这是证明 CRDT 版本控制可以处理困难 UX 问题并给出更好答案的证据——以及构建真实东西的一致设计。"

代码是公共领域的。完整设计文档在 README 中。

版本控制的未来可能不是另一个 Git 分支——它可能是一个完全不同的范式。