为什么你的 Git 工作流正在拖累你： Jujutsu 入门指南

你每天用 Git，但有没有想过：Git 那些复杂到头疼的操作，到底是在解决什么问题？

我最近开始用 Jujutsu（简称 JJ），这是一个由 GitHub 工程师 Ted生子（Martin von Zweydorf）开发的版本控制工具。用了两周之后，我想说：这才应该是 2026 年程序员默认的版本控制系统。

Git 哪里出了问题

不是说 Git 不好。Git 解决了它那个年代的问题。但 2026 年的代码协作模式，跟 2005 年 Linux 内核开发时代相比，已经发生了根本性变化。

Git 的分支模型适合「每个开发者独立贡献代码，定期合并」的模式。但现代开发不是这样的：我们在 feature 分支之间穿梭，处理 rebase vs merge 的哲学争论，为了一个冲突解决要动用 beyond compare。这些都是精神内耗。

真正的问题是：我们用 Git 管理的「历史」太多了。每一个 commit、每一个 merge、每一个 cherry-pick，都构成了我们所谓的「项目历史」。但这个历史，99% 的情况下没有任何人需要看。

Jujutsu 解决的是什么

Jujutsu 的核心理念是：分布式开发，但本地历史只属于你。

在 JJ 的模型里，你每次「commit」，本质上是一次本地快照。这个快照不会自动同步到远程。你可以在本地随意 rebase、squash、改写历史，而不影响任何其他人。只有当你明确「push」的时候，这些变化才会成为「共享历史」的一部分。

听起来有点熟悉？没错，有点像 Git 的 amend 和 rebase，但 JJ 把这些做成了默认行为，而不是需要特殊标志的操作。

安装和基础配置

macOS 安装：

brew install jj

Linux：

cargo install jj

Windows 通过 WSL2 是最顺滑的方式，或者用 Scoop：

scoop bucket add jj https://github.com/jj-tools/scoop-jj
scoop install jj

你的第一个 Jujutsu 工作流

1. 初始化（等价于 git init）

jj git init my-project
cd my-project

JJ 会自动初始化一个 Git 后端存储，但它不创建「main」或「master」分支——它创建一个叫 @ 的符号，指向你当前的「工作位置」。

2. 写代码，然后「描述」你的变化

echo "# My Project" > README.md
jj diff

你会看到 JJ 没有用「暂存区」的概念。你改了什么，它就显示什么。

3. 创建提交

jj new
jj describe -m "Add README"

jj new 创建一个新 change（JJ 的术语），jj describe 设置描述。这比 Git 的三步走（git add → git commit → git commit message）少了一步。

4. 分支操作：Jujutsu 的虚拟分支

这是最有趣的部分。在 JJ 里，你不需要创建本地分支来隔离工作。你在 @ 上工作，这个 @ 可以通过「描述」来区分不同任务。

如果你真的需要并行工作线，JJ 用的是「虚拟分支」——同一个 commit 对象上，可以有多个描述不同的 change 叠加。这比 Git 的分支模型灵活得多。

5. 与远程仓库同步

jj git push

push 的时候，JJ 会把你的本地 change 转化为一个 Git remote ref。默认情况下，所有本地 history 都是私有的，只有 push 出去的 change 才是共享的。

为什么 Jujutsu 值得学

我用 JJ 两周，有几个明显感受：

第一，merge 不再是噩梦。 JJ 的 merge 算法比 Git 智能得多。最常见的「我的改动 vs 别人的改动」冲突，JJ 能自动解决的概率比 Git 高很多。

第二，rebase 是本地操作。 我可以随时 rebase 我的本地 change 来整理历史，不需要担心这个操作会影响到其他人的工作。这对代码审查前的「整理提交」非常有用。

第三，undo 比 Git 更安全。 JJ 的每个操作都是不可变的，通过操作日志可以回溯到任意时刻。这意味着没有「reflog」这种需要手动管理的逃生通道——所有历史都在那里。

局限性：Jujutsu 适合什么场景

JJ 不是一个 Git 替代品。如果你的团队已经用 Git 并且运作良好，没有必要迁移。

但如果你遇到以下场景，JJ 值得考虑：

大型 monorepo，分支管理复杂度高
频繁的跨分支 cherry-pick 操作
需要本地实验性开发的个人项目
代码审查前需要频繁整理提交历史

另外，JJ 兼容 Git——你可以把一个 JJ 仓库当作纯 Git 仓库使用，也可以用 Git 命令操作同一个存储。这使得迁移成本很低。

与 GitHub 的集成

JJ 目前对 GitHub 的支持还在完善中。但基本的 pull/push 功能可用。

配置 GitHub：

jj git push -r origin -d @

这会把当前 change 推送到 origin 的一个 remote branch。

一个建议

如果你对 JJ 感兴趣，第一步不是把所有项目迁移过去。找一个个人项目，先用 JJ 管理三个月，感受一下「没有分支压力」的版本控制是什么体验。

很多 Git 的复杂度来自于「我要管理很多分支」这个心理模型。当这个模型消失，很多操作会自然简化。

2026 年，Git 的问题不是「不够强大」，是「太复杂了」。 Jujutsu 是给这个问题的第一个认真思考后的答案。