Jujutsu（简称 JJ）的创造者 Martin von Zweigbergk 已加入 East River Source Control（ERSC），担任 CTO，开始参与下一代版本控制平台的创业实践。这个变化值得关注的地方，不只是一个开源项目核心人物的职业变动，更在于它释放了一个信号：版本控制仍然存在足够大的产品空间，Git 也并非开发者工作流的终点。
从业余项目到全职系统
Martin 在 2019 年底启动 Jujutsu，最初是一个业余项目，后来发展为他在 Google 的全职工作。Jujutsu 由 Google 内部孵化而来，之后以 Apache 2.0 许可证开源，在 GitHub 上获得了超过 3 万个 star。
这条路径说明，版本控制工具的创新并不一定来自一次宏大的平台重写，也可能从一个工程师对日常痛点的持续修正开始。随着项目从个人实验变成组织内的生产级工作，工具需要同时面对提交历史管理、协作流程、分支模型、兼容性和迁移成本等问题。
Jujutsu 的定位是 Git 的现代替代品。这里的“替代”不应简单理解成一次命令行工具更换，而应理解为对版本控制基本交互方式的重新设计：开发者如何表达当前工作、如何整理变更、如何同步远程仓库，以及如何在复杂协作中保持可理解的历史。
为什么下一代版本控制仍有机会
Git 的生态极其成熟，几乎所有代码托管平台、CI 系统和开发工具都围绕它建立。但成熟也意味着大量历史包袱：命令语义需要长期兼容，分支和暂存区等概念形成了固定心智模型，团队还积累了大量围绕 Git 的脚本和流程。
因此，新的版本控制平台要获得采用，通常不能只强调“命令更简单”。它需要在几个方面同时建立优势：
- 工作流模型：让开发者更容易描述当前修改，而不是频繁管理工具内部状态。
- 历史整理能力：支持在提交、拆分、合并和重排之间进行更自然的操作。
- Git 互操作性：在迁移早期继续使用已有的远程仓库、代码托管平台和协作工具。
- 团队级可靠性：不仅个人体验流畅，还要适应审查、自动化构建和多人协作。
- 可持续的产品形态：开源客户端之外，还需要解决企业使用、托管服务和技术支持等问题。
ERSC 的成立及 Martin 出任 CTO，意味着这类探索可能从开源工具进一步延伸到商业化平台。对开发团队来说，真正值得观察的不是公司名称本身，而是平台能否把新的版本控制模型转化为稳定、可迁移、可协作的工程产品。
可以怎样体验 Jujutsu
下面是一个最小实验流程。假设本机已经安装了与当前版本匹配的 jj，并准备了一个测试目录。命令用于体验基本工作流，具体参数应以所安装版本的帮助信息为准。
# 创建一个只用于实验的目录，并初始化 Git 兼容仓库
mkdir jj-playground
cd jj-playground
jj git init
# 创建文件并查看工作区状态
printf 'hello\n' > README.md
jj status
# 为当前修改添加描述
jj describe -m "Add initial README"
# 创建一个新的工作变更，继续下一项开发
jj new
printf 'next change\n' >> README.md
jj status
# 查看变更历史
jj log
这个实验的重点不是记住几条命令，而是观察工作区、变更和历史之间的关系。实际评估时，可以把一个小型非关键项目迁移到独立目录，比较以下任务的操作成本：整理多个修改、拆分变更、在代码审查前重排历史，以及与现有 Git 远程仓库同步。
团队不应直接把新工具推到所有仓库。更稳妥的做法是选择一个依赖较少的试点项目，记录开发者学习成本、CI 改造量、代码审查体验和回滚路径，再决定是否扩大范围。由于 Git 生态仍然是主流，Git 兼容能力和工具链集成会直接影响迁移风险。
开发团队需要关注什么
Martin 加入 ERSC 后，Jujutsu 的发展和下一代版本控制平台之间可能形成新的连接，但目前仅凭这一职业变动，无法判断 ERSC 最终产品的具体架构、发布时间或商业模式。工程团队应把事实与期待分开：已知的是核心创造者正在创业公司继续推进版本控制方向；尚待验证的是新平台会采用什么模型，以及它能否在真实团队中替代现有 Git 流程。
评估这类工具时，可以保留一份简单清单：
- 是否能与现有 Git 仓库和远程服务协作？
- 新工作流是否减少了日常操作，而不是增加另一套抽象？
- IDE、代码审查、CI 和发布系统是否有可用集成？
- 团队成员能否在短时间内理解恢复、同步和历史整理？
- 出现问题时，能否导出、回退并回到熟悉的 Git 工具链？
版本控制的下一场竞争，不会只发生在命令名称上。它更可能发生在“开发者如何组织变化”以及“团队如何共享变化”这两个层面。Jujutsu 已经证明，Git 之外的设计可以获得广泛关注；ERSC 接下来要证明的，则是这种设计能否成为可靠的平台。