jj-vcs/jj 源: https://github.com/jj-vcs/jj

Jujutsu——一个版本控制系统

发布版 (https://github.com/jj-vcs/jj/releases) | 发布日期 (https://github.com/jj-vcs/jj/releases) | 许可证 (https://github.com/jj-vcs/jj/blob/main/LICENSE) | Discord (https://discord.gg/dkmfj3aGQN) | IRC (https://web.libera.chat/?channel=#jujutsu)

**首页 • ** **安装 • ** **入门指南 • ** **开发路线图 • ** 参与贡献

简介

Jujutsu 是一个为软件项目设计的强大版本控制系统 (https://en.wikipedia.org/wiki/Version_control)。你可以用它获取代码副本、追踪代码变更，并最终将这些变更发布给他人查看和使用。它从设计之初就力求易用——无论你是新手还是经验丰富的开发者，无论你是独自开发全新项目，还是与团队协作大型软件项目（拥有庞大历史和众多团队成员），都能轻松上手。

Jujutsu 与大多数其他系统不同之处在于，它将用户界面和版本控制算法与用于提供内容的存储系统在内部进行了抽象。这使得它可以成为一个支持多种物理后端的 VCS，这些后端可能拥有自己的数据或网络模型——例如 Mercurial 或 Breezy，或者混合系统如 Google 基于云的设计 Piper/CitC。

如今，我们使用 Git 仓库作为存储层来提供和追踪内容，使其能够与许多你喜爱的基于 Git 的工具兼容，现在就可用！ 但请注意，只有提交和文件存储在 Git 中；书签（分支）和其他更高级的元数据存储在 Git 外部的自定义存储中。所有核心开发者都使用 Jujutsu 在 GitHub 上开发 Jujutsu 本身。不过，它也应该能与你自己喜爱的 Git 托管平台兼容。

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

• Git: 我们努力追求速度——通过流畅的用户体验、高效的算法、正确的数据结构和老派的注重细节。默认存储后端使用 Git 仓库进行“物理存储”，以实现广泛互操作性和易于上手。
• Mercurial & Sapling: 借鉴了许多 Mercurial 启发的特性，例如用于选择提交的 revset 语言。没有显式的索引或暂存区。分支像 Mercurial 一样是“匿名的”，因此你无需为每个小改动想一个名字。用于重写历史的基本操作强大且简单。输出格式化通过一个用户可配置的健壮模板语言完成。
• Darcs: Jujutsu 在其模型中将冲突作为一等对象来追踪；它们与提交一样是一等的，而 Git 等替代方案仅仅将冲突视为文本差异。虽然不如 Darcs（基于形式化的补丁理论，而非快照）那样严谨，但其效果是，许多形式的冲突解决可以自动执行和传播。

此外，它还增加了几个自己创新的、有用的特性：

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

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

• 安全、并发的复制：你是否曾经想把版本控制下的仓库存放在 Dropbox 文件夹中？或者持续将仓库备份到 S3？没有？好吧，现在你可以了！在典型的 Git/Mercurial 仓库上使用 Dropbox 这类文件系统和 rsync 等备份工具的根本问题在于，它们依赖于本地文件系统操作的原子性、序列化以及与其它读写操作的非并发性——这在操作分布式文件系统或在进行并发文件复制（用于备份）时持有锁文件的情况下，是不成立的。Jujutsu 的设计则是在并发场景下是安全的；仅仅使用 rsync 或 Dropbox，然后使用生成的仓库，绝不应导致仓库处于损坏状态。最坏的情况应该是暴露本地和远程状态之间的冲突，让你解决它们。

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

Jujutsu 相对年轻，还有很多工作要做。如果你有任何问题，或想讨论未来计划，请加入我们的 Discord (https://discord.gg/dkmfj3aGQN)，开始 GitHub 讨论 (https://github.com/jj-vcs/jj/discussions)，或在 Libera Chat 上向 #jujutsu 发送 IRC 消息 (https://web.libera.chat/?channel=#jujutsu)。开发者们会监控所有这些渠道¹。

新闻与动态 📣

• 2024 年 12 月：jj 仓库已迁移至 jj-vcs GitHub 组织。
• 2024 年 11 月：0.24 版本发布，新增了 jj file annotate，相当于 git blame 或 hg annotate。
• 2024 年 9 月：Martin 在 Git Merge 2024 上发表了关于 Jujutsu 的演讲。
• 2024 年 2 月：0.14 版本发布，弃用了 “jj checkout” 和 “jj merge”，以及 jj init --git，现在简称为 jj git init。
• 2023 年 10 月：0.10.0 版本发布！现在包含适用于所有平台的捆绑合并与差异编辑器、“不可变修订集”以避免意外 edit 错误的修订版本，以及大量打磨。
• 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 月：LWN.net 发表了一篇题为 Jujutsu: 一个新的、兼容 Git 的版本控制系统 的文章。
• 2023 年 1 月：Martin 在 Git Merge 2022 上关于 Jujutsu 的演讲，视频和相关的幻灯片。

维基百科也包含了一份更详尽的媒体引用列表。

入门指南

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

请遵循安装说明 (https://docs.jj-vcs.dev/latest/install-and-setup) 来获取并配置 jj。

开始的最佳方式可能是阅读教程 (https://docs.jj-vcs.dev/latest/tutorial)。另请参阅 Git 比较 (https://docs.jj-vcs.dev/latest/git-comparison)，其中包含一个 jj 与 git 命令的对照表。

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

• FAQ (https://docs.jj-vcs.dev/latest/FAQ)。
• 术语表 (https://docs.jj-vcs.dev/latest/glossary)。
• jj help 命令（例如 jj help rebase）。
• jj help -k <关键词> 命令（例如 jj help -k config）。使用 jj help --help 查看可用的关键词。

如果你使用的是 预发布版 的 jj，你应查阅预发布版（主分支）的文档 (https://docs.jj-vcs.dev/prerelease/)。你也可以通过网站上的版本切换器从最新版本的文档中访问它。当你滚动到任何页面顶部时，版本切换器会显示在网站的页眉中。

特性

与 Git 兼容

Jujutsu 的设计使得底层数据和存储模型是抽象的。目前，只有 Git 后端可用于生产环境。Git 后端使用 gitoxide (https://github.com/Byron/gitoxide) Rust 库。

Git 后端功能齐全且维护良好，允许你使用任何 Git 远程仓库与 Jujutsu 配合。你创建的提交看起来就像普通的 Git 提交。你可以从普通的 Git 远程仓库获取分支，并将分支推送到远程仓库。你随时可以切换回 Git。以下是你如何使用 jj 探索 GitHub 仓库。你甚至可以拥有一个共置的本地工作区，在其中可以互换使用 jj 和 git 命令。

工作副本自动提交

Jujutsu 使用一个真实的提交来表示工作副本。检出某个提交会在目标提交之上生成一个新的工作副本提交。几乎所有命令都会自动修订工作副本提交。工作副本作为一个提交意味着命令永远不会因为工作副本“脏”而失败（没有“错误：您对以下文件的本地修改…”），也无需使用 git stash。此外，由于工作副本是一个提交，命令在工作副本提交上的行为与在任何其他提交上相同，因此你可以在完成更改之前设置提交消息。

仓库是真理之源

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

整个仓库都受版本控制

你在仓库中执行的所有操作都会被记录下来，同时记录操作后的仓库状态快照。这意味着你可以轻松恢复到早期的仓库状态，只需逐个撤销操作，甚至还原某个特定操作（该操作不必是最新的操作）。

冲突可以记录在提交中

如果某个操作导致冲突 (https://docs.jj-vcs.dev/latest/glossary#conflict)，则有关这些冲突的信息将被记录在提交中。该操作仍将成功。你可以稍后解决冲突。这种设计的一个结果是无需继续中断的操作。相反，你获得了一个用于解决冲突的单一工作流，无论哪个命令导致了它们。这种设计还让 Jujutsu 能够正确变基合并提交（与 Git 和 Mercurial 都不同）。

基本冲突解决： Juggling conflicts：

自动变基

每当你修改一个提交时，旧提交的任何后代都会自动变基到新提交上。得益于上述的冲突设计，即使存在冲突，也能完成变基。指向已变基提交的书签将被更新。如果工作副本指向一个已变基的提交，它也会被更新。

全面支持重写历史

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

状态

该工具功能相当完整，但一些重要功能（如支持 Git 子模块）尚未完成。也存在一些性能问题。很可能工作流程和设置如果与核心开发者使用的不同，则支持不佳，例如没有原生支持基于邮件的工作流程。

目前，所有核心开发者都使用 jj 来开发 jj。我（Martin von Zweigbergk）自 2021 年 1 月初以来几乎完全使用 jj 来开发该项目本身。我从未需要从源代码重新克隆（我想我甚至从未需要从备份恢复）。在 1.0.0 版本之前，将会 有工作流程上的变化以及磁盘格式的不向后兼容更改。对于任何格式更改，我们将尽力实现透明的升级（就像我们在最近的更改中所做的那样），或者根据要求提供升级命令或脚本。

相关工作

有几个工具试图解决与 Jujutsu 类似的问题。请参阅相关工作 (https://docs.jj-vcs.dev/latest/related-work) 了解详情。

参与贡献

我们欢迎外部贡献，而且有很多事情可以做，所以不要害羞。如果你想了解你可以帮忙做的事情，请尽管问，希望我们能一起找到办法。我们确实有一些供贡献者参考的策略和建议。

简而言之：

• 非常欢迎错误报告！
• 每个进入 main 分支的提交都会经过代码审查。
• 请遵守规矩，并遵守社区准则。
• 有一个必须同意的强制性 CLA。重要的是，它不会将版权转让给 Google 或任何其他人；它只是授予我们安全地重新分发和使用你的更改的权利。