Jujutsu——一个版本控制系统

<br/>

</div>

简介

Jujutsu是一个强大的软件项目版本控制系统。你可以用它来获取代码副本，跟踪代码变更，最后发布这些变更供他人查看和使用。无论你是新手还是经验丰富的开发者，无论是独自开发全新项目，还是参与大型软件项目的团队合作，它都设计得易于使用。

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

目前，我们使用Git仓库作为存储层来提供和跟踪内容，**这使得它与许多你喜欢的基于Git的工具兼容，现在就可以使用！**所有核心开发者都在这里的GitHub上使用Jujutsu来开发Jujutsu。它应该也能与你喜欢的Git代码托管平台兼容。

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

Git：我们努力保持快速——通过敏捷的用户体验、高效的算法、正确的数据结构，以及对细节的关注。默认存储后端使用Git仓库作为"物理存储"，以实现广泛的互操作性和便于上手。
Mercurial & Sapling：有许多受Mercurial启发的功能，如用于选择提交的revset语言。没有显式的索引或暂存区。分支是像Mercurial一样的"匿名"分支，所以你不需要为每个小变更起名字。重写历史的原语既强大又简单。输出格式化是通过用户可配置的强大模板语言完成的。
Darcs：Jujutsu将冲突作为其模型中的一等公民进行跟踪；它们与提交一样是一等公民，而像Git这样的替代方案只是将冲突视为文本差异。虽然不像Darcs那样严格（Darcs基于形式化的补丁理论，而不是快照），但效果是许多形式的冲突解决可以自动执行和传播。

它还添加了几个创新、有用的自身特性：

工作副本作为提交：对文件的更改[自动记录][wcc]为普通提交，并在每次后续更改时进行修改。这种"快照"设计简化了面向用户的数据模型（提交是唯一可见的对象），简化了内部算法，并完全包含了Git的贮藏或索引/暂存区等功能。
操作日志和撤销：Jujutsu记录对仓库执行的每个操作，从提交到拉取再到推送。这使得调试"刚刚发生了什么？"或"我是如何到达这里的？"等问题变得更容易，尤其是当你在帮助同事解答关于他们仓库的这些问题时！而且因为一切都被记录下来，你可以轻松撤销刚刚犯的错误。版本控制终于进入了[20世纪60年代][undo-history]！
自动变基和冲突解决：当你修改一个提交时，每个后代都会自动在新修改的提交之上重新变基。这使得"基于补丁"的工作流程变得轻而易举。如果你在一个提交中解决了冲突，该冲突的解决方案也会传播到后代。实际上，这是一个完全透明的git rebase --update-refs与git rerere的组合版本，由设计支持。

[!警告] 以下功能可供使用，但处于实验阶段；它们可能存在bug、向后不兼容的存储更改和用户界面更改！

安全、并发复制：你是否曾经想过将版本控制的仓库存储在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的计划！可以查看幻灯片或录像。

入门

[!重要] Jujutsu是一个实验性版本控制系统。虽然Git兼容性是稳定的，大多数开发者每天都在使用它满足所有需求，但可能仍有正在开发的功能、次优的用户体验和工作流程空缺，这可能使它不适用于你的特定用途。

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

开始使用的最佳方式可能是完成教程。另外，请查看Git对比，其中包括jj与git命令的对照表。

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

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

如果你正在使用预发布版本的jj，你可能需要参考预发布（主分支）版本的文档。你也可以通过网站的版本切换器从最新发布版本的文档到达那里。当你滚动到任何页面顶部时，版本切换器会在网站头部可见。

特性

与Git兼容

Jujutsu的设计使底层数据和存储模型是抽象的。目前，它有两个后端——一个使用Git仓库进行存储，另一个是原生存储后端。

Git后端功能齐全且得到维护，允许您将Jujutsu用作Git的替代界面。您创建的提交将看起来像常规的Git提交。您随时可以切换回Git。Git支持使用libgit2 C库。

您甚至可以有一个"并置"的本地仓库，在那里您可以交替使用jj和git命令。

工作副本会自动提交

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

工作副本作为一个提交意味着命令永远不会因为工作副本不干净而失败（不会出现"错误：您对以下文件的本地更改..."），也不需要使用git stash。此外，由于工作副本是一个提交，命令在工作副本提交上的操作方式与在任何其他提交上相同，因此您可以在完成更改之前设置提交消息。

仓库是事实来源

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

整个仓库都在版本控制之下

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

冲突可以记录在提交中

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

基本冲突解决：

处理冲突：

自动变基

每当您修改一个提交时，旧提交的任何后代都会被变基到新提交上。由于上面描述的冲突设计，即使存在冲突也可以完成这一操作。指向变基提交的分支将被更新。如果工作副本指向变基的提交，它也会被更新。

全面支持重写历史

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