Jujutsu 对比 Git：Git 一直没有的那个 undo

git 的 reflog 救得回你的 commit，救不回你在 commit 上跑错的那条命令。这道缝——撤销操作，而不只是 commit——就是 Jujutsu 的全部论点。读完项目的公开记录而不是它的宣传之后，我的结论是：这个论点比怀疑者们以为的更站得住。

本站的 Undo Anything in Git hub 之所以存在，是因为 git 的撤销叙事是碎的：reset、revert、reflog，各管各的规则。jj 押注的是：碎片化本身就是设计缺陷。

Jujutsu 是什么，凭什么拿它和 git 比？

jj 是一套兼容 Git 的版本控制系统：GitHub 31,796 颗星、376 位贡献者、2020 年 12 月首个 release，此后月月不断——从 2025 年 11 月的 v0.35 到 2026 年 9 月的 v0.45.1，十二个 release 全部落在每月第一周，稳得像上了发条。这篇帖子发布当天早上，仓库还推了新提交。

「兼容 Git」是最容易被忽略的部分。jj 默认拿 Git 仓库当存储后端——README 写得明明白白：commit 和文件都以 git 格式存放，所以你的 clone、remote、托管平台和 CI 一律照旧。大家都在搜的 jujutsu vs git 其实问错了框架：jj 更像是给你已经信任的存储换了一层新界面。Meta 的 Sapling 押了反方向——自建存储后端，所以迁移到它意味着离开更多 git 生态。

operation log 能做哪些 git 做不到的事？

这才是这篇评测真正值钱的设计决策。git 在 reflog 里记录的是 commit——误丢的工作大约 90 天内可找回。但你的仓库是怎么一步步变成 mess 的，reflog 并不关心。revert 还是 reset 的抉择之所以存在，就是因为 git 逼你在还不知道哪条命令对的时候，先选对命令。

jj 把每一步操作——每一次 rebase、每一次 abandon、每一次 squash——都记进 operation log。README 自己的话：“因为一切都有记录，你刚犯的那个错可以轻松撤销。” jj op log 展示仓库状态的历史，jj undo 沿着它一步步往回走。rebase 错了？Undo。reset 错了地方？Undo。git 给数据的安全网，jj 给了自己的操作。

git 的撤销叙事假设你会选对命令，jj 的假设是你不会。

冲突真是一等公民吗？

是，而且这一点对团队协作的改变比撤销还大。git 把合并冲突当成工作区的临时状态——现在解决，或者放弃。jj 把冲突作为对象存进历史：一个带冲突的 commit 可以存在、可以提交、甚至可以推送。之后再解决冲突，jj 会自动把修复传播到所有后代提交——和你改了早期提交后整条提交栈自动 rebase，是同一个机制。

真实项目里的效果——叠起来的变更自己 rebase 自己——就是说服力的来源。摘自 Hacker News 上讨论 jj 工作流的帖子（236 分）：

“叠 PR 加多分支 rebase 变得毫不费力。冲突是历史里真实存在的东西，可以留到以后处理。一切都自动提交，所以搞砸 reset/stash pop 也不会丢工作。” — hellcow

最后一句值得细品。jj 的工作区本身就是一个 commit，每次改动都在 amend 它。没有 stash，因为没有东西需要 stash——切分支时，进行中的工作作为 commit 跟着你走。另一位在公司里（全员 git）切换到 jj 的评论者说：“0 个问题。”

公开记录里反对 jj 的部分是什么？

诚实的账本，因为记录里确实有：

• 诚实的 0.x。 月月发版，也意味着每月有十二次机会遇到破坏性变更。项目跑得快，而且明说了。
• bookmarks 不存在 git 里。 commit 和文件用 git 存储，分支元数据用 jj 自己的格式。colocated clone 能把两边桥接起来，但这是多出来的一块要理解的东西。
• 1,262 个 open issue。 项目健康，backlog 也是真的。
• 怀疑者也有说对的地方。 那个 HN 帖子里票数最多的保留意见：“jj 我读过好多遍了，还是不明白它到底解决什么问题。” 如果你的 git 工作流就是单分支加偶尔 merge，operation log 不会改变你的一周。收益属于叠提交、冲突历史和大量撤销的日子——也就是 git undo 生成器有流量的那些日子。

该从 git 换到 jj 吗？

基于记录的结论，外加强制的那句诚实声明：我读的是记录，没有亲手跑。 这里的每个数字和引文都来自仓库、它的 README 和公开的 HN 帖子——不是来自我的终端。

记录支持的做法：在个人项目上用 colocated 方式试试 jj——一个 clone，两套工具，零迁移。底下的对象就是 git 的对象，你的 git 知识直接复用。团队可以一人一人地采用，因为 jj 推上去的就是普通的 git commit。记录不支持的做法：把成熟团队一口气迁过去，或者在钉版本 soak 之前，让 0.x 工具碰发布关键自动化。

撤销的缝隙是真实的，设计是自洽的；互操作性把最常见的借口拿掉了，剩下的最后一道坎叫习惯。

用一周的肌肉记忆，换一本连工具自身操作都覆盖的撤销日志——你换吗？说句实话：上次 reset 丢工作的时候，reflog 真的全都找回来了吗？