Jujutsu：一个既简单又强大的 Git 兼容版本控制系统

"

前言：当 Git 遇到"简化版"

想象这样一个场景：

你是一个 Git 用户，每天要和 staging area、branch naming、commit history 做斗争。你常常想：

"为什么每次修改都要 git add？" "为什么每次小改动都要想个分支名？" "为什么撤销一个操作这么复杂？" "为什么冲突处理这么痛苦？"

现在，有一个叫做 Jujutsu（简称 jj）的项目，试图回答这些问题。

它是一个 Git 兼容的版本控制系统，既简单又强大。

今天，我们就来探索这个试图"简化 Git"的野心项目。

---

一、Jujutsu 是什么？

1.1 核心定位

Jujutsu 是一个强大的版本控制系统，用于软件项目的代码管理。

核心特点：

• ✅ Git 兼容：使用 Git 作为存储层，可与现有 Git 工具互操作
• ✅ 简单易用：无需 staging area，匿名分支，直观的工作流
• ✅ 功能强大：自动 rebase、冲突作为一等对象、操作日志和撤销
• ✅ 创新设计：工作副本即提交、自动冲突传播、并发复制安全

设计目标：

"无论是新手还是专家，无论是个人项目还是大规模团队协作，都能轻松使用。"

1.2 为什么是"Jujutsu"？

命名由来：

• 命令行工具叫 jj：因为简单易输入，且在英语中罕见
• 项目叫 "Jujutsu"：与 "jj" 匹配（类似 "Git" 与 "git"）

寓意：

• Jujutsu（柔术）是一种以柔克刚的武术
• 暗示这个工具试图以"柔"的方式解决 Git 的"刚"性问题

---

二、核心特性：从 Git 中学到的教训

2.1 Git 兼容：无缝迁移

核心设计：

"Jujutsu 将用户界面和版本控制算法与存储系统抽象分离。"

实现方式：

• 使用 gitoxide Rust 库作为 Git 后端
• 将 commits 和 files 存储在 Git 中
• bookmarks（分支）和其他元数据存储在自定义存储中
• 可以与任何 Git remote 互操作

实际效果：

# 使用 jj 克隆 GitHub 仓库
jj git clone https://github.com/user/repo

# 在 jj 中工作
jj status
jj log
jj commit

# 可以切换回 Git
git log
git status

Colocated Workspace：

• 可以在同一个目录下同时使用 jj 和 git 命令
• 无缝切换，无需迁移
• 逐步适应，降低风险

2.2 无需 Staging Area：自动提交

Git 的痛点：

# Git 的典型工作流
git add file1.txt          # 添加到 staging area
git add file2.txt          # 再添加
git commit -m "..."         # 提交

问题：

• staging area 是额外的认知负担
• 新手常常忘记 git add
• "我修改了文件，为什么 commit 不包含？"

Jujutsu 的简化：

"Working-copy-as-a-commit：文件更改自动记录为普通提交，每次后续修改都会自动修正。"

效果：

• 无需 jj add 命令
• 文件修改自动记录
• commit 自动修正
• 完全替代 Git 的 staging area 和 stash

示例：

# Jujutsu 的工作流
# 1. 修改文件
echo "hello" > file.txt

# 2. 直接提交（无需 add）
jj commit -m "Add hello"

# 3. 再次修改文件
echo "world" >> file.txt

# 4. 直接修正上一个提交（无需 add）
jj amend

2.3 匿名分支：无需命名

Git 的痛点：

# Git 的分支管理
git checkout -b feature/login           # 每个小改动都要想分支名
git checkout -b fix/login-error
git checkout -b refactor/login-code
git checkout -b update/login-tests
# ...（分支爆炸）

问题：

• 每个小改动都要创建分支
• 分支命名是认知负担
• 分支清理是额外工作

Jujutsu 的简化：

"Branches are 'anonymous' like Mercurial—you don't need to make up a name for each small change."

效果：

• 无需为小改动创建分支名
• 可以创建大量匿名提交
• 只在真正需要时才命名分支

示例：

# Jujutsu 的工作流
# 1. 创建一系列匿名提交
jj commit -m "Add login UI"
jj commit -m "Fix login error"
jj commit -m "Refactor login code"

# 2. 只在需要时才创建分支
jj branch create main

2.4 自动 Rebase：历史管理自动化

Git 的痛点：

# Git 的 rebase 流程
git rebase -i HEAD~3           # 交互式 rebase
# ...（手动解决冲突）
git rebase --continue
# ...（再次解决冲突）
git rebase --continue

问题：

• 手动 rebase 复杂且容易出错
• 冲突需要反复解决
• 需要记住 --update-refs 等选项

Jujutsu 的自动化：

"When you modify a commit, every descendant is automatically rebased on top of the freshly-modified one."

效果：

• 修改提交时，后代自动 rebase
• 冲突解决自动传播
• 相当于透明的 git rebase --update-refs + git rerere

示例：

# Jujutsu 的自动化
# 1. 创建一系列提交
jj commit -m "Add feature A"
jj commit -m "Add feature B"
jj commit -m "Add feature C"

# 2. 修改第一个提交
jj edit <commit-A-id>

# 3. 后续提交自动 rebase（无需手动操作）

---

三、核心特性：创新功能

3.1 冲突作为一等对象

Git 的痛点：

# Git 的冲突处理
git merge feature-branch
# CONFLICT (content): Merge conflict in file.txt
# Auto-merging failed; fix conflicts and then commit the result.

问题：

• 冲突只是文本差异
• 冲突状态难以追踪
• 冲突解决无法自动传播

Jujutsu 的创新：

"Jujutsu keeps track of conflicts as first-class objects in its model."

效果：

• 冲突是版本控制模型的一等对象
• 冲突可以像提交一样被追踪和管理
• 冲突解决可以自动传播到后代提交

灵感来源：Darcs（基于形式化的补丁理论）

3.2 操作日志和撤销

Git 的痛点：

# Git 的撤销操作
git reset --hard HEAD~1        # 误操作？数据丢失！
git reflog                     # 试图找回
# ...（手动查找和恢复）

问题：

• 误操作可能导致数据丢失
• reflog 是隐藏功能，新手不知道
• 撤销操作复杂且不直观

Jujutsu 的创新：

"Jujutsu records every operation that is performed on the repository, from commits, to pulls, to pushes."

效果：

• 所有操作都被记录
• 可以轻松撤销任何操作
• "版本控制终于进入了 1960 年代！"（Undo 功能诞生于 1960 年代）

示例：

# Jujutsu 的操作日志
jj log --operations           # 查看操作历史

jj undo                       # 撤销最后一个操作
jj undo -o 3                  # 撤销倒数第三个操作

3.3 安全的并发复制

Git 的痛点：

# Git 的复制问题
cp -r my-repo Dropbox/
# ...（在另一台机器上修改）
cp -r Dropbox/my-repo ./
# Git 仓库可能损坏！

问题：

• Git 依赖本地文件系统的原子性
• 在 Dropbox、rsync 等场景下可能损坏
• 并发读写不安全

Jujutsu 的创新：

"Jujutsu is designed to be safe under concurrent scenarios."

效果：

• 可以安全地存储在 Dropbox 中
• 可以持续备份到 S3
• 并发复制不会导致仓库损坏
• 最坏情况：暴露冲突，而非数据损坏

实验性功能：此功能仍处于实验阶段

---

四、设计哲学：从其他 VCS 中学习

4.1 从 Git 中学习

学到的：

• ✅ 快速：高效的算法、正确的数据结构、细节关注
• ✅ 互操作：使用 Git 作为物理存储，易于上手

改进的：

• ❌ 移除了 staging area 的复杂性
• ❌ 简化了分支管理
• ❌ 自动化了 rebase 流程

4.2 从 Mercurial & Sapling 中学习

学到的：

• ✅ Revset 语言：强大的提交选择语言
• ✅ 无 staging area：简化工作流
• ✅ 匿名分支：无需为小改动命名
• ✅ 强大的历史重写：简单且强大
• ✅ 模板语言：可配置的输出格式

4.3 从 Darcs 中学习

学到的：

• ✅ 冲突作为一等对象：冲突可以被追踪和管理
• ✅ 自动冲突传播：冲突解决自动传播到后代

---

五、实际使用：从 Git 迁移到 Jujutsu

5.1 安装

官方文档：https://docs.jj-vcs.dev/latest/install-and-setup

安装方式：

• macOS：brew install jujutsu
• Linux：从 GitHub Releases 下载二进制文件
• 其他：参考官方文档

5.2 快速开始

1. 克隆现有 Git 仓库：

jj git clone https://github.com/user/repo
cd repo

2. 查看状态：

jj status

3. 查看日志：

jj log

4. 创建提交：

# 修改文件
echo "hello" > file.txt

# 直接提交（无需 add）
jj commit -m "Add hello"

5. 修改历史：

# 修改上一个提交
jj amend

# 修改任意提交
jj edit <commit-id>

6. 撤销操作：

# 撤销最后一个操作
jj undo

5.3 与 Git 并用

Colocated Workspace：

# 在同一个目录下使用 jj 和 git
jj log           # jj 查看日志
git log          # git 也可以工作

jj commit        # jj 提交
git commit       # git 也可以提交

效果：

• 无需迁移
• 无缝切换
• 逐步适应

---

六、核心价值：简化还是增强？

6.1 简化的价值

1. 降低认知负担

• ❌ 无需理解 staging area
• ❌ 无需为小改动命名分支
• ❌ 无需手动 rebase
• ❌ 无需担心误操作

2. 提高效率

• ✅ 减少命令数量
• ✅ 自动化繁琐操作
• ✅ 直观的工作流

3. 降低学习曲线

• ✅ 新手友好
• ✅ 无需学习复杂概念
• ✅ 从 Git 平滑迁移

6.2 增强的价值

1. 更强大的功能

• ✅ 操作日志和撤销
• ✅ 冲突作为一等对象
• ✅ 自动 rebase 和冲突传播
• ✅ 安全的并发复制

2. 更好的可扩展性

• ✅ 抽象的存储层
• ✅ 可支持多种后端（Git、Mercurial、Breezy）
• ✅ 可支持云基础架构（Google Piper/CitC）

---

七、局限性与挑战

7.1 实验性状态

官方提醒：

"Jujutsu is an experimental version control system."

含义：

• Git 兼容性是稳定的
• 大多数开发者日常使用没问题
• 但仍可能有工作流缺陷、UX 问题

7.2 生态不成熟

现状：

• 社区较小
• 工具支持有限
• 文章和教程较少
• 问题解决依赖社区

7.3 学习曲线

问题：

• 虽然 UI 简化了，但核心概念仍然复杂
• 从 Git 迁移需要适应期
• 某些 Git 功能可能缺失

---

八、适用场景

8.1 适合的人群

1. Git 疲劳者

• 厌倦了 Git 的复杂性
• 想要更简单的工作流
• 希望降低认知负担

2. 个人开发者

• 个人项目
• 小型团队
• 不需要复杂的分支策略

3. 实验爱好者

• 愿意尝试新工具
• 可以接受实验性状态
• 愿意为社区贡献

8.2 不适合的人群

1. 企业团队

• 需要稳定工具
• 需要完善的工具链
• 需要官方支持

2. Git 重度用户

• 已经习惯 Git 工作流
• 依赖复杂的 Git 功能
• 不想迁移成本

3. 保守用户

• 不愿意尝试实验性工具
• 需要成熟生态
• 需要长期稳定性保证

---

九、未来展望

9.1 项目状态

当前阶段：

• ✅ Git 后端生产就绪
• ✅ 核心功能稳定
• ⚠️ 仍在快速发展
• ⚠️ 可能有破坏性变更

9.2 发展方向

1. 完善功能

• 补齐缺失的 Git 功能
• 改进 UX
• 修复工作流缺陷

2. 扩展生态

• 更多工具支持
• 更多教程和文档
• 更大的社区

3. 多后端支持

• Mercurial 后端
• Breezy 后端
• 云端存储（如 Google Piper）

---

十、总结

10.1 核心回顾

Jujutsu 的核心价值：

1. 简化 Git 的复杂性

   • 无 staging area
   • 匿名分支
   • 自动 rebase

2. 增强 Git 的功能

   • 操作日志和撤销
   • 冲突作为一等对象
   • 安全的并发复制

3. 保持 Git 兼容

   • 使用 Git 作为存储层
   • 可与现有 Git 工具互操作
   • 无缝切换和迁移

10.2 革命性意义

"版本控制的 1960 年代"：

Git 让我们进入了版本控制的现代世界，但 Jujutsu 让我们进入了"1960 年代"——因为 Undo 功能诞生于 1960 年代。

从"手动操作"到"自动管理"：

• Git：手动 add、手动 rebase、手动解决冲突
• Jujutsu：自动提交、自动 rebase、自动传播冲突

从"工具驱动"到"工作流驱动"：

• Git：你需要理解工具的工作原理
• Jujutsu：工具适应你的工作流

10.3 最终思考

Jujutsu 不是要替代 Git，而是要回答一个问题：

"如果我们从零开始设计一个版本控制系统，它会是什么样子？"

答案：

• 更简单（无需 staging area、匿名分支）
• 更强大（操作日志、冲突作为对象）
• 更兼容（Git 后端、无缝切换）

这就是 Jujutsu 的野心：一个既简单又强大的 Git 兼容版本控制系统。

---

参考资源

• 官方主页：https://www.jj-vcs.dev
• 安装文档：https://docs.jj-vcs.dev/latest/install-and-setup
• 入门教程：https://docs.jj-vcs.dev/latest/tutorial
• Git 对比：https://docs.jj-vcs.dev/latest/git-comparison
• GitHub 仓库：https://github.com/jj-vcs/jj
• Discord 社区：https://discord.gg/dkmfj3aGQN

---

如果你觉得这篇文章有帮助，欢迎点赞、转发，让更多人了解这个野心勃勃的版本控制项目！