「Jujutsu」不是咒术回战：一个版本控制工具的作者，离开 Google 去修 Git 的天花板

目录

• 名字梗背后的真身
• 他给 Google 的十万工程师修过路
• jj 到底革了什么命
• 「笔记本革命了，服务器没跟上」
• 社区光谱：商标是 Google 的，代码不是
• 现场验证：change-id 真的活着穿过 push 吗
• 收束：终点还是服务器

---

引言

9 月 1 日，Hacker News 上出现一条帖子：「The creator of Jujutsu has joined ERSC」，262 分。评论区第一条高赞回复是：

What a pivot, from manga to software

——从漫画到软件，好大的转型。

但这是个误会。这里的 Jujutsu 不是《咒术回战》，而是一个版本控制工具。它的作者 Martin von Zweigbergk 也没去画漫画——他离开了待了十多年的 Google，加入了一家叫 East River Source Control（ERSC）的公司，当 CTO。

误会好笑，但误会底下压着一个真正值得琢磨的问题：一个给 Git「换脑子」的人，为什么最终选择离开大厂，去一家创业公司？他要在服务器上动的那一刀，到底切的是什么？

名字梗背后的真身

先把这个名字说清楚。Jujutsu（简称 jj）是一个 Git 兼容的分布式版本控制系统，2019 年末开始作为 Martin 的 side project 存在，后来在 Google 变成他的全职工作。GitHub 上 31,000+ stars，Apache 2.0 协议——不是 Google 的私产，是一个开放项目，只是主要维护者恰好在 Google 上班。

「Jujutsu」这个名字来自日语的「柔术」，和《咒术回战》（Jujutsu Kaisen）撞了同一个词根。所以 HN 评论区才会出现「从漫画转型到软件」这种梗——一个版本控制工具，因为名字，被误认成一部热血漫的主角。

这个误会本身挺有意思：如果你以为它是漫画，那它 31,000 颗星就变成了「动漫粉丝量」；如果你知道它是版本控制，那 31,000 颗星意味着 31,000 个仓库把工作流押在了它身上。

他给 Google 的十万工程师修过路

Martin 的履历，是这条新闻里最容易被低估的部分。

在写 jj 之前，他做过 Fig——一个 Mercurial 客户端，给 Google 工程师在 Piper 上提供分布式工作流。Piper 是 Google 的 monorepo，几乎整个公司的代码都住在那里面。换句话说，Google 十万级工程师每天 push/pull 的体验，有一部分是他铺的。

他还给 Git 本身贡献过代码。Git 是 96% 的开发者（2022 Stack Overflow 调查）在专业场景使用的工具，是全球软件开发的地基之一。踩在地基上的人很多，真正弯下腰去修地基的人很少。

然后他花了六年时间，把 jj 从一个 side project 养成了 GitHub 上最受关注的版本控制实验——然后在 2026 年 8 月，离开 Google。

jj 到底革了什么命

jj 的核心设计，一句话说：提交不再是历史里的一个点，而是一个可以在时间线上自由拖动的对象。

传统 Git 的工作流是「分支 + 提交」：你想改一个 commit，要么 amend，要么 rebase，要么 cherry-pick，三板斧轮着上，rebase 冲突的时候血压跟着上。jj 把「commit」拆成两层——change-id（身份）和 commit（快照）。change-id 是稳定的、属于某个逻辑改动的；commit 只是它在某个时刻的样子。

这意味着你可以随便 amend、随便 reorder、随便 split——因为 change-id 不会变，你的「逻辑改动」始终能对上号。协作时，别人 rebase 了你的 commit，你 pull 下来还是能认出「哦，这是我的那个改动」，而不是看到一个陌生的 hash。

Git 十年没解决的「rebase 之后认不出彼此」问题，jj 用「给改动一个永久的名字」解决了。

「笔记本革命了，服务器没跟上」

现在到 ERSC 的论点。Martin 在官方公告里说了一段关键的话：

Jujutsu improves the part of version control that sits on your laptop. But the remote server is still Git, which has a ceiling that comes fast for products at scale. We think the storage layer has to change to match the model, and that work can be better supported by a company than an open source project.

翻译过来：jj 革的是你笔记本上那一半的命。但远端服务器还是 Git——而 Git 的存储层，规模化之后会很快撞上天花板。存储层必须跟着变。

这是整条新闻里最锋利的一句。本地革命再热闹，代码最终都要 push 到某个地方；而那个地方，二十多年了，还是 Git 的对象存储。ERSC Storage 这个月进入 private beta——他们要动的，正是服务器那一半。

为什么会撞天花板？Git 的存储模型是「不可变对象 + 引用」：每个 commit 是一棵完整的对象树，历史越长、分支越密，服务器上要存和要算的东西越多。AI 时代代码生成量暴涨、agent 每秒制造几十个 commit、monorepo 膨胀——Git 服务器那一层，成了整条流水线上最古典、最不动的部件。

社区光谱：商标是 Google 的，代码不是

HN 评论区没有只停留在「恭喜」上。Steve Klabnik（Rust 名人，和 ERSC 关系密切）下场澄清了一连串所有权细节：

• jj 之前挂在 Google 的 GitHub 账号下，现在迁到了自己的 org（jj-vcs/jj）
• Google 拥有 jj 的商标，但不拥有代码的版权——没有 copyright assignment，贡献者保留自己的权利
• 他的类比：「Google 之于 jj，就像 Mozilla 之于 Rust」——公司雇了维护者，但项目始终是 Apache 2.0 的开源项目

评论区有人提醒创业者：「Google 拥有商标」在投资人尽调时是个红旗——哪怕实际上 Google 对代码没有所有权。另一些人则更关心技术：jj 的 change-id 会不会真的跨仓库保留？copy tracking 什么时候来？

这场讨论最耐人寻味的地方是：一个版本控制工具的人事变动，能把「开源项目所有权」「商标」「投资人尽调」「分布式存储」全串起来——因为版本控制本身就是软件行业的「地基行业」，动地基，所有人都会探头看。

现场验证：change-id 真的活着穿过 push 吗

评论区 dzaima 提到了一个具体的机制：jj 会把 change-id 写进 Git commit object 的 header 里，即使 push 到远端也原样保留。普通 git log 看不到它，但它确实在那里。

这种「看不见但存在」的说法，最值得亲手验一遍。我在服务器上装好 jj 0.45.0（正好今天发布），建了一个和我博客仓库同构的 colocated 仓库——同一个目录里同时跑 git 和 jj：

jj 0.45.0-8da2b7b45a09e740a777a1daa25d6aa45ebadbd8

用 jj 做了两个提交，然后看底下的 Git commit object header：

tree 2f8a498da992f2962b1193f1e32c9848e4a4e979
parent a572d629ce5a421562979ebcd294fe9c3bbcda93
author JJ_EMPTY_STRING <JJ_EMPTY_STRING> 1788437938 +0800
committer JJ_EMPTY_STRING <JJ_EMPTY_STRING> 1788437938 +0800
change-id kuvwwyzpxlxqyunnqrmtqnrruzxrzxtw

change-id 真的在 header 里。 然后我把分支推到本地建的一个 bare 仓库（模拟 GitHub/GitLab），再从远端把 commit 读出来：

change-id tpqyzppvnxvuzqlutqvxulxmouxzvqyp

push 之后还在。 而 git log --oneline 的输出里，完全看不到这一行——普通工具、普通服务器、普通的 Git，都对这个字段视而不见。

这就是文章开头那个悖论的实体版：jj 的改动，端到端地穿过了 Git 的管道，但 Git 自己永远不知道它运了什么。 本地已经革命了，服务器只是忠实地、盲目地搬运。

（唯一的小翻车：jj push 需要先给 bookmark 建 track 关系，第一次直接 jj git push 被「Refusing to create new remote bookmark」拦下——这个报错本身就是 jj 和 Git 思维差异的缩影：jj 眼里没有「分支」，只有可追踪的书签。）

收束：终点还是服务器

这场人事变动的分量，不在「又一个大厂工程师离职创业」，而在它把版本控制二十多年的分工摊开来看清了：

笔记本那一半，jj 证明可以革——change-id 让 rebase 不再是认亲大会；服务器那一半，Git 的存储层还站在原地。Martin 用六年证明本地可以不同，现在他要证明服务器也可以不同。

至于「Jujutsu 是不是咒术回战」——评论区那个梗，笑得越响，越说明一个事实：版本控制对大多数人来说，是背景噪音一样的存在。直到有人要给它换引擎，你才意识到，全世界写代码的人，脚底下踩的都是同一块地板。