介绍

聚宝盆是一个强大的软件项目版本控制系统。您可以使用它来获取代码副本、跟踪代码更改，最后发布这些更改供他人查看和使用。它从头开始设计，易于使用——无论是新手还是老手，独自进行全新的项目，还是具有大量历史和团队的规模庞大的软件项目。

聚宝盆与其他大多数系统不同，因为它在内部抽象了用户界面和版本控制算法，使其从用于提供内容的 存储系统 中分离出来。这使得它能够作为一个具有许多可能物理后端（可能具有自己的数据或网络模型）的VCS，例如 Mercurial 或 Breezy，或者是像Google基于云的设计 Piper/CitC 这样的混合系统。

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

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

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

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

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

并且它还增加了自己的一些创新、有用的功能

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

• 操作日志 & 撤销：Jujutsu会记录对仓库执行的所有操作，从提交到拉取，再到推送。这使得调试问题如“刚才发生了什么？”或“我是如何到达这里的？”变得容易，尤其是在帮助同事回答他们仓库中的问题时！由于一切都已记录，你可以轻松撤销刚才犯的错误。版本控制终于进入了20世纪60年代！

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

[!WARNING] 以下功能可用，但处于实验性状态；它们可能存在错误、向后不兼容的存储更改和用户界面更改！

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

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

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

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

Jujutsu 相对较新，还有很多工作要做。如果您有任何问题，或者想讨论未来的计划，请加入我们的 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 对 Jujutsu 计划的演讲！请参阅 幻灯片 或 录音。

相关媒体

• 2024年3月：Chris Krycho 开始了一个关于 Jujutsu 的 YouTube 系列节目。
• 2024年2月：Chris Krycho 发表了一篇关于 Jujutsu 的文章，题为 jj init，Steve Klabnik 也跟进发布了 Jujutsu 教程。
• 2024年1月：Jujutsu 被LWN.net 的一篇文章 Jujutsu: a new, Git-compatible version control system 介绍。
• 2023年1月：Martin 在 Git Merge 2022 上的关于 Jujutsu 的演讲，视频 和相关的 幻灯片。

入门指南

[!IMPORTANT] Jujutsu 是一个 实验性版本控制系统。尽管与 Git 的兼容性稳定，并且大多数开发者每天都会使用它来满足所有需求，但可能仍然存在正在开发中的功能、次优的用户体验和工作流程中的差距，这可能会使其对您的特定用途不可用。

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

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

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

• 常见问题解答。
• 术语表。
• 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 使用实际的提交来表示工作副本。检出提交会在目标提交之上创建一个新的工作副本提交。几乎所有命令都会自动修改工作副本提交。

由于工作副本是一个提交，因此命令永远不会因为工作副本不干净（没有“error: 您对以下文件的本地更改...”）而失败，也不需要 git stash。此外，由于工作副本是提交，因此命令在处理工作副本提交时与处理任何其他提交的方式相同，因此您可以在完成更改之前设置提交信息。

仓库是真相之源

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

整个仓库都受到版本控制

您在仓库中进行的所有操作都会被记录，包括操作后的仓库状态快照。这意味着您可以轻松地恢复到早期的仓库状态，或者简单地撤销特定的操作（这不必是最近的操作）。

冲突可以记录在提交中

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

基本冲突解决

处理冲突

自动变基

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

对历史重写的全面支持

除了常规的变基命令外，还有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（贡献者许可协议）您必须同意。重要的是，它不会将版权所有权转让给谷歌或任何人；它仅仅给予我们安全地重新分发和使用您更改的权利。

强制性的谷歌免责声明

我（马丁·冯·齐格贝克，martinvonz@google.com）于2019年底将Jujutsu作为一个爱好项目开始，它已经发展成为我在谷歌的全职项目，有几位其他谷歌员工（现在）以各种方式协助开发。话虽如此，这并不是一个谷歌产品。

许可证

Jujutsu是开源软件，根据Apache 2.0许可证提供。有关版权和重新分发详情，请参阅LICENSE。