Git 太难用了？这个叫 Jujutsu 的新工具，想把版本控制从“玄学”拉回人类世界
一个新工具，敢对 Git 的统治地位提出疑问
在程序员世界里，Git 的地位有点像键盘上的 QWERTY 布局：大家都知道它不算完美，甚至常常骂它难用，但你几乎不可能绕开它。新手第一次面对 rebase、reset、reflog、detached HEAD 这些词时，往往会产生一种错觉：我到底是在管理代码，还是在参加某种咒语考试？
就在这样的背景下，Rust 社区知名开发者 Steve Klabnik 发布了 Jujutsu（命令行工具名为 jj）教程的入门章节，开门见山地抛出一个很大胆的判断：jj 比 Git 更简单、更容易，同时还更强大。老实说，这种表述很容易让人本能地皱眉。技术世界讲究权衡，功能强的工具通常更复杂，越“傻瓜”的东西越难兼顾灵活性。可 Jujutsu 恰恰想挑战这个惯性认知。
它不是要推翻分布式版本控制这套逻辑，相反，它仍然是一套 DVCS，也就是分布式版本控制系统。真正不同的地方在于，Jujutsu 试图重新整理开发者和版本历史之间的关系：不是让人记住一堆危险命令，再小心翼翼地操作历史；而是把常见工作流重新设计得更自然，让版本控制更像“整理思路”，而不是“拆炸弹”。
Jujutsu 到底新在哪儿：它不是另一个 Git 前端
如果只把 jj 理解成“更好看的 Git 命令包装器”，那就低估它了。按照教程中的说法，Jujutsu 吸收了 Git 和 Mercurial（hg）两套传统 DVCS 的优点，做出了一个既陌生又熟悉的系统。这个描述其实很微妙。陌生，是因为它的核心操作方式和 Git 并不完全一致；熟悉，是因为它并没有强迫你抛弃现有仓库、团队协作和远程平台。
Jujutsu 最吸引人的地方，在我看来并不是“命令更少”这么简单，而是它在试图减少版本控制里的“心理负担”。Git 的问题从来不只是命令难背，而是很多操作会让人担心自己是不是把历史搞坏了。你在本地改了几次提交，准备整理一下历史，脑子里就会自动浮现两个问题：这一步会不会把分支弄乱？我等会儿还能不能推上去？Git 的高手当然会说，这些都能解决；但问题恰恰在于，一个工具如果总需要高手来安抚新手，那就说明设计本身并不友好。
Jujutsu 的思路更像是：既然开发者修改历史、拆分提交、合并变更、同时处理多条工作线，是再正常不过的事情，那这些能力就应该成为“默认舒适区”，而不是只有在读完三篇博客、看完两个视频之后才敢碰的高级技巧。教程目录里提到的匿名分支、revsets、同时处理多个分支、stacked PR 等内容，已经暴露了它的野心——它不是在修修补补 Git 的边角，而是在重写很多大家早已习惯忍受的工作流。
最关键的一点：它兼容 Git，所以你几乎没有试错成本
Jujutsu 最聪明的一步，是没有选择和 Git 正面决裂。它提供 Git 兼容后端，这意味着开发者完全可以自己在本地用 jj，而团队其他人继续使用 Git、GitHub、现有 CI/CD 流程，照样可以协作。这一点非常重要，因为开发工具历史上失败的案例太多了：技术上也许更优雅，但只要迁移成本高、生态不兼容，基本就很难出圈。
这也是为什么我认为 Jujutsu 比很多“下一代开发工具”更有现实机会。程序员通常不是不愿意尝新，而是不愿意为了一个可能更好的工具，去承担团队协作的额外摩擦。换句话说，jj 不是要求整个公司下周一集体改信仰，它更像是一种可渐进试用的替代方案。你今天就能在自己的仓库里试，明天不喜欢再切回 Git，历史也不会丢。这种“可逆性”在工程工具里特别宝贵。
从传播策略上看，这也很高明。过去很多工具死在“必须全员迁移”这件事上，而 Jujutsu 选择了一条更务实的路：先服务那些最容易被 Git 折磨到的人，再慢慢从个体使用渗透到团队习惯。对于经常做代码审查、频繁改 PR、喜欢把提交历史整理干净的开发者来说，它的吸引力尤其强。
为什么是现在：AI 写代码越多，版本控制越需要被重做
Jujutsu 在这个时间点受到关注，并不只是因为它更好用一点。更深层的原因是，软件开发的形态正在变化。过去，程序员主要是自己敲代码、自己组织改动；现在，越来越多人会让 AI 辅助生成代码，再由人类二次修改、拆分、验证和重构。这种开发方式会带来一个新问题：代码变更多了、更碎了、更需要整理。
Git 诞生于另一个时代。它非常适合管理大规模代码协作，也经受住了 Linux 内核这样的超复杂项目考验。但它的很多日常交互，仍然带着那个年代的工程审美：强调底层能力、强调灵活、默认使用者愿意理解内部模型。今天的软件开发者并没有变笨，只是他们的注意力要分给更多事情——云服务、依赖安全、自动化测试、AI 代码审查、跨团队协作。版本控制如果还是那个“你先学会自救”的工具，就越来越像一块不必要的认知税。
Jujutsu 抓住的正是这个缝隙：既然版本控制本质上是帮助人类表达“这段改动是什么、和另一段改动有什么关系”，那它就应该服务于思维，而不是反过来训练人类适应工具。Steve Klabnik 把它描述成“更简单也更强大”，听起来像营销语，但放到今天这个时间点，它的确切中了一个现实需求：开发者比过去更需要整理变化，而不是仅仅存储变化。
当然，真正的问题也在这里。一个工具能否成功，不只取决于设计是否优秀，还取决于它是否能建立起足够稳定的心智模型。Git 虽然痛苦，但它的“痛苦”已经被社区文档、教程、无数 Stack Overflow 问答和团队规范消化掉了。Jujutsu 要想走得更远，不能只靠“更友好”的第一印象，还要证明自己在复杂团队、超大型仓库、长期维护场景里一样靠得住。
它会取代 Git 吗？未必，但它可能改变我们对版本控制的期待
我不太相信 Jujutsu 会在短期内“杀死 Git”。这件事几乎不可能。Git 的护城河不是功能，而是生态、习惯和历史包袱——而这三样东西恰恰最难撼动。就像你很难让整个互联网同时改掉某种协议一样，版本控制系统一旦坐稳主流位置，后来者更多是在边上蚕食，而不是一夜翻盘。
但我反而觉得，这不妨碍 Jujutsu 变得重要。因为它真正可能带来的影响，不是让大家卸载 Git，而是逼着整个开发工具链重新思考一个问题：为什么到了 2026 年，程序员还在为“怎么优雅地改一串提交历史”这种事焦虑？如果 jj 证明了版本控制可以更符合直觉、更少陷阱、更适合现代协作，那么哪怕最终多数人还是留在 Git 阵营，这场尝试也已经有价值。
Mercurial 当年没有赢下 Git，但它对版本控制体验的很多探索一直在影响后来者。今天的 Jujutsu，也许会扮演类似角色。它像是给整个行业发出的一次提醒：别把开发者受苦当成理所当然，更别把复杂误认为专业。工具应该让人更勇敢地修改历史、表达意图、整理工作，而不是让人一看到 force push 就心跳加速。
从记者的角度看，这类新闻最迷人的地方在于，它不是一次热闹的融资，也不是某家巨头的发布会，而是一种基础工具层面的悄悄松动。很多真正改变软件世界的事，往往不是从舞台中央开始的，而是从一群开发者终于受够了某个老问题开始的。Jujutsu 现在还远未成为主流，但它至少让人看到：版本控制这件事，原来还可以重新发明。