简介

Jujutsu是一个强大的版本控制系统，适用于软件项目。您可以使用它获取代码副本，跟踪代码更改，并最终发布这些更改供他人查看和使用。它从一开始就被设计成易于使用——无论您是新手还是老手，独自工作在新项目上，还是在具有悠久历史和团队的规模软件项目上。

Jujutsu与其他系统不同，因为它在内部将用户界面和版本控制算法从用于提供服务内容的存储系统抽象出来。这使得它可以作为具有许多可能的物理后端的VCS，这些后端可能有它们自己的数据或网络模型——如Mercurial或Breezy，或者是像谷歌基于云的设计Piper/CitC这样的混合系统。

今天，我们使用Git仓库作为存储层来服务和跟踪内容，使其现在就与许多您喜欢的基于Git的工具兼容！所有核心开发者都使用Jujutsu在GitHub上开发Jujutsu。但它也希望能够与您喜欢的Git forge兼容。

我们将来自其他版本控制系统的许多独特的设计选择和概念结合到一个工具中。这些灵感来源包括

• Git：我们努力使它变得快速——拥有流畅的用户界面、高效的算法、正确的数据结构和一丝不苟的细节关注。默认的存储后端使用Git仓库进行“物理存储”，以实现广泛的互操作性和易于上手。

• Mercurial & Sapling：有许多以Mercurial为灵感的特性，例如用于选择提交的revset语言。没有显式的索引或暂存区。分支像Mercurial一样是“匿名”的，所以你不需要为每次小改动想一个名字。修改历史记录的原始功能强大且简单。输出格式化使用的是用户可配置的健壮模板语言。

• Darcs：Jujutsu将其模型中的冲突跟踪为一等对象；它们与提交一样是一等对象，而像Git这样的替代方案只是简单地将冲突视为文本差异。虽然不如Darcs（它基于补丁的正规化理论，而不是快照）那样严格，但结果是许多形式的冲突解决可以自动执行和传播。

并且它还增加了自己的一些创新、实用的特性

• 工作副本作为提交：对文件的更改自动记录为正常的提交，并在每次后续更改时进行修订。这种“快照”设计简化了面向用户的数据模型（提交是唯一可见的对象），简化了内部算法，并完全包含了像Git的暂存或索引/暂存区这样的功能。

• 操作日志 & 撤销：Jujutsu记录在仓库上执行的每个操作，从提交到拉取、推送。这使得调试诸如“刚才发生了什么？”或“我是怎么到这里的？”等问题变得更容易，尤其是当你帮助同事回答他们仓库中的这些问题时！而且因为所有操作都被记录，你可以轻松地撤销刚才犯的错误。版本控制终于进入了20世纪60年代！

• 自动变基和冲突解决：当你修改一个提交时，每个后代都会自动在最新修改的基础上进行变基。这使得“基于补丁”的工作流程变得轻松。如果你在一个提交中解决了冲突，该冲突的解决也会传播到后代。实际上，这是一个完全透明的版本，结合了git rebase --update-refs和git rerere，这是设计支持的。

[!WARNING] 以下特性可供使用，但处于实验阶段；它们可能有错误、向后不兼容的存储更改和用户界面更改！

• 安全、并发复制：你是否想过将你的版本控制系统存储在Dropbox文件夹中？或者持续将仓库备份到S3？如果没有？现在你可以了！

  在典型的Git/Mercurial仓库上使用像Dropbox这样的文件系统和像rsync这样的备份工具的基本问题是，它们依赖于本地文件系统操作是原子的、序列化的、与其他读取和写入非并发的——这在操作分布式文件系统时是不成立的，或者当并发文件复制（用于备份）发生时，锁定文件正在被持有。

  忍术设计为在并发场景下更安全；简单使用rsync或Dropbox，然后使用生成的仓库，永远不会导致仓库处于损坏状态。最坏的情况是，它将暴露本地和远程状态之间的冲突，留给你去解决。

命令行工具目前称为jj，因为它容易输入且容易替换（在英语中很少见）。该项目被称为“忍术”，因为它与“jj”匹配。

忍术相对较新，还有很多工作要做。如果您有任何问题，或想讨论未来的计划，请加入我们的Discord 或开始一个GitHub讨论；开发者会监视这两个渠道。

新闻和更新 📣

• 2024年2月：发布了版本0.14，弃用了"jj checkout"和"jj merge"，以及jj init --git，现在只称为jj git init。
• 2023年10月：发布了版本0.10.0！现在包含适用于所有平台的捆绑合并和差异编辑器，“不可变修订集”以避免意外编辑错误的修订，以及许多改进。
• 2023年1月：Martin在Git Merge 2022上做了一次关于Google对忍术计划的演讲！查看幻灯片或录像。

相关媒体

• 2024年3月：Chris Krycho开始了一个关于忍术的YouTube系列。
• 2024年2月：Chris Krycho发表了一篇关于忍术的文章，名为jj init，Steve Klabnik随后发布了忍术教程。
• 2024年1月：忍术在LWN.net的一篇文章中被介绍，标题为忍术：一个新的、与Git兼容的版本控制系统。
• 2023年1月：Martin在Git Merge 2022上关于忍术的演讲，视频和相关的幻灯片。

维基还包含一个更全面的媒体引用列表。

入门

[!IMPORTANT] 忍术是一个实验性版本控制系统。虽然Git兼容性稳定，并且大多数开发者每天都会用它来满足所有需求，但可能仍然存在一些正在开发中的功能、不理想的UX和工作流程差距，这可能会使其不适合您的特定用途。

按照安装说明获取和配置jj。

入门的最佳方式可能是通过教程。还可以查看Git比较，其中包含jj与git命令的表格。

随着您对忍术越来越熟悉，以下资源可能会有所帮助

• 常见问题解答。
• 术语表。
• jj help命令（例如jj help rebase）。

如果您正在使用 预发布版 的 jj，您应该查阅 预发布版（主分支）的文档。您也可以通过网站上的版本切换器从最新发布版本的文档中找到它。版本切换器在您将任何页面的顶部滚动时在网站页眉中可见。

特性

兼容 Git

Jujutsu 设计得使底层数据和存储模型是抽象的。今天，它有两个 后端——其中一个使用 Git 仓库进行存储，而另一个是原生存储后端[^native-backend]。

[^native-backend]：目前，实际上没有理由使用原生后端。后端主要存在是为了确保最终能够添加无法轻松添加到 Git 后端的函数。

Git 后端功能齐全且维护良好，允许您将 Jujutsu 作为 Git 的替代接口使用。您创建的提交将看起来像常规的 Git 提交。您始终可以切换回 Git。Git 支持使用 libgit2 C 库。

您甚至可以有一个 “位于同一位置”的本地仓库，在其中您可以交替使用 jj 和 git 命令。

工作副本自动提交

Jujutsu 使用真实的提交来表示工作副本。检出提交会在目标提交之上产生一个新的工作副本提交。几乎所有的命令都会自动修改工作副本提交。

工作副本作为一个提交意味着命令永远不会因为工作副本是脏的（没有“错误：您对以下文件进行了本地更改...”）而失败，并且不需要 git stash。此外，由于工作副本是提交，命令在工作副本提交上的工作方式与在任何其他提交上一样，因此您可以在完成更改之前设置提交信息。

仓库是真相的来源

在 Jujutsu 中，与 Git 相比，工作副本扮演的角色较小。命令在开始之前快照工作副本，然后更新仓库，然后更新工作副本（如果工作副本提交已被修改）。几乎所有命令（甚至是 checkout！）都在仓库的提交上操作，将工作副本的快照和更新功能留给集中式代码。例如，jj restore（类似于 git restore）可以从任何提交恢复到任何提交，而 jj describe 可以设置任何提交的提交信息（默认为工作副本提交）。

整个仓库处于版本控制之下

您在仓库中执行的任何操作都会被记录，以及操作后仓库状态的快照。这意味着您可以轻松地回滚到较早的仓库状态，或者简单地撤销特定操作（这不一定是最新的操作）。

冲突可以记录在提交中

如果操作导致 冲突，则有关这些冲突的信息将记录在提交（s）中。操作将成功。然后您可以稍后解决冲突。这种设计的一个后果是，无需继续中断的操作。相反，您会得到一个解决冲突的单个工作流程，无论哪个命令导致冲突。这种设计还允许 Jujutsu 正确地 rebase 合并提交（与 Git 和 Mercurial 都不同）。

基本冲突解决

处理冲突

自动 rebase

每次修改提交时，旧提交的所有后代都会被变基到新提交上。多亏了上面描述的冲突设计，即使在有冲突的情况下也能完成。指向变基提交的分支将被更新。如果工作副本指向一个变基提交，它也将被更新。

全面支持重写历史记录

除了常规的变基命令外，还有 jj describe 用于编辑任意提交的描述（提交信息）。还有 jj diffedit，它允许您在不检出提交的情况下编辑提交中的更改。要拆分提交为两个，请使用 jj split。您甚至可以使用 jj squash -i --from X --into Y 将提交中的一部分更改移动到任何其他提交。

状态

该工具功能相当全面，但一些重要功能（如 git blame 的等效功能）尚不支持。还有几个性能问题。可能不会很好地支持与核心开发者使用的不同的工作流程和设置，例如，没有基于电子邮件的工作流程的原生支持。

今天，所有核心开发者都使用 jj 在 jj 上工作。自从2021年1月初以来，我（马丁·冯·齐格贝格克）几乎完全使用 jj 来开发项目本身。我甚至不需要从源代码重新克隆（我认为我甚至不需要从备份中恢复）。

在版本1.0.0之前，工作流程将会有所改变，磁盘格式将会有不兼容的更改。甚至二进制文件名也可能改变（即不再使用 jj）。对于任何格式更改，我们将尝试实现透明的升级（正如我们最近所做的），或者在需要时提供升级命令或脚本。

相关工作

有几个工具试图解决与 Jujutsu 类似的问题。有关详细信息，请参阅 相关工作。

贡献

我们欢迎外部贡献，有很多事情要做，所以不要害羞。如果您想了解您可以帮忙的事情，请提出问题，希望我们都能找到解决方案。

我们为贡献者有一些建议和政策。简而言之

• 欢迎提交错误报告！
• 进入 main 分支的每个提交都经过代码审查。
• 请自我约束，并遵守社区指南。
• 存在一项强制性的 CLA，您必须同意。重要的是，它 不会 将版权所有权转让给 Google 或其他人；它只是授予我们安全地重新分配和使用您更改的权利。

强制性的 Google 声明

我（马丁·冯·齐格贝格克，[email protected]）在2019年底开始将 Jujutsu 作为一项爱好项目，并在 Google 发展为全职项目，几名其他谷歌工程师（现在）在各个层面上协助开发。话虽如此，这并不是一个 Google 产品。

许可证

Jujutsu 是开源软件，遵循 Apache 2.0 许可证。有关版权和重新分配的详细信息，请参阅 LICENSE。