jj-vcs/jj 源代码：https://github.com/jj-vcs/jj # Jujutsu——一款版本控制系统

Release (https://github.com/jj-vcs/jj/releases) Release date (https://github.com/jj-vcs/jj/releases) License (https://github.com/jj-vcs/jj/blob/main/LICENSE) Discord (https://discord.gg/dkmfj3aGQN) IRC (https://web.libera.chat/?channel=#jujutsu)

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

简介

Jujutsu 是一款面向软件项目的强大版本控制系统。你可以用它获取代码副本、追踪代码变更，并最终将这些变更发布供他人查看和使用。它从设计之初就以易用性为核心目标——无论你是新手还是老手，无论是独立开发全新项目，还是参与拥有庞大历史记录和团队的大型软件项目。

Jujutsu 与大多数同类系统截然不同，因为它在内部将用户界面和版本控制算法从用于托管内容的存储系统中抽象出来。这使它能够作为一个支持多种物理后端的 VCS，这些后端可以拥有各自的数据或网络模型——例如 Mercurial、Breezy，或者像 Google 基于云端设计的混合系统 Piper/CitC。

目前，我们使用 Git 仓库作为存储层来托管和追踪内容，使其现在就能与你喜爱的许多基于 Git 的工具兼容！ 但请注意，只有提交和文件存储在 Git 中；书签（分支）及其他高级元数据存储在 Git 之外的自定义存储中。

所有核心开发者都在 GitHub 上使用 Jujutsu 来开发 Jujutsu 本身。它也应该能与你喜欢的 Git 托管平台配合使用。

我们将来自其他版本控制系统的诸多独特设计理念和概念融合到了一个工具中。部分灵感来源包括：

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

此外，它还新增了几项创新且实用的特性：

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

以下功能可供使用，但仍处于实验阶段；可能存在 bug、不向后兼容的存储变更以及用户界面变更！

• 安全的并发复制：你是否曾想过将版本控制仓库存储在 Dropbox 文件夹中？或者将仓库持续备份到 S3？没有？好吧，现在你可以了！将 Dropbox 等文件系统和 rsync 等备份工具用于典型 Git/Mercurial 仓库的根本问题在于，它们依赖本地文件系统操作的原子性、串行性，以及与其他读写操作的非并发性——而在分布式文件系统上运行，或在持有锁文件时发生并发文件复制（用于备份）等操作时，这些条件并不成立。Jujutsu 的设计目标是在并发场景下保证安全；直接使用 rsync 或 Dropbox 同步后再使用该仓库，永远不应导致仓库处于损坏状态。最坏的情况应该是暴露本地与远程状态之间的冲突，留给你来解决。

命令行工具暂时称为 jj，因为它易于输入且便于替换（在英语中较为罕见）。项目名称“Jujutsu“是因为它与“jj“相对应。

Jujutsu 相对年轻，还有大量工作有待完成。如有任何问题，或想讨论未来计划，欢迎加入我们的 Discord Discord (https://discord.gg/dkmfj3aGQN)，发起 GitHub Discussion (https://github.com/jj-vcs/jj/discussions)，或在 Libera Chat (https://web.libera.chat/?channel=#jujutsu) 上向 #jujutsu 频道发送 IRC 消息。开发者会关注所有这些渠道¹。

新闻与更新 📣

• 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 错误修订的“不可变 revset“，以及大量细节打磨。
• 2023 年 1 月：Martin 在 Git Merge 2022 上发表了关于 Google Jujutsu 计划的演讲！查看幻灯片或录像。

相关媒体

• 2024 年 3 月：Chris Krycho 开始了关于 Jujutsu 的 YouTube 系列视频。
• 2024 年 2 月：Chris Krycho 发表了一篇关于 Jujutsu 的文章 jj init，Steve Klabnik 随后发布了 Jujutsu Tutorial。
• 2024 年 1 月：Jujutsu 在 LWN.net 的一篇名为 Jujutsu: a new, Git-compatible version control system 的文章中被重点介绍。
• 2023 年 1 月：Martin 在 Git Merge 2022 上关于 Jujutsu 的演讲，视频及对应幻灯片。

Wiki 中还有一份更全面的媒体参考列表。

入门指南

Jujutsu 是一款实验性版本控制系统。虽然 Git 兼容性已趋于稳定，且大多数开发者每天将其用于所有需求，但仍可能存在进行中的功能、欠佳的用户体验以及工作流缺口，导致它无法满足你的特定使用场景。

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

入门的最佳方式可能是完成教程。另请参阅 Git 对比，其中包含 jj 与 git 命令的对照表。

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

• 常见问题解答
• 词汇表
• jj help 命令（例如 jj help rebase）
• jj help -k <关键词> 命令（例如 jj help -k config）。使用 jj help --help 查看可用关键词。

如果你使用的是预发布版的 jj，建议查阅预发布（main 分支）版本的文档。你也可以从最新发布版的文档中通过网站的版本切换器跳转到预发布文档。版本切换器在任意页面滚动到顶部时，会显示在网站页头处。

特性

与 Git 兼容

Jujutsu 的设计使其底层数据和存储模型是抽象的。目前，只有 Git 后端已达到生产可用状态。Git 后端使用 gitoxide Rust 库。

Git 后端功能完整且持续维护，允许你将 Jujutsu 与任何 Git 远程仓库配合使用。你创建的提交看起来与普通 Git 提交无异。你可以从普通 Git 远程拉取分支，也可以向远程推送分支。你随时都可以切换回 Git。

以下是如何使用 jj 探索 GitHub 仓库的方式。你甚至可以拥有一个本地协同工作区，在其中交替使用 jj 和 git 命令。

工作副本自动提交

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

工作副本作为提交意味着命令不会因工作副本有未提交修改而失败（不会出现“error: Your local changes to the following files…“），也无需使用 git stash。此外，由于工作副本是一个提交，命令对工作副本提交和其他任意提交的处理方式完全相同，因此你可以在完成修改之前就设置提交信息。

仓库是唯一的真相来源

在 Jujutsu 中，工作副本扮演的角色比 Git 中更小。命令在开始前会对工作副本进行快照，然后更新仓库，最后再更新工作副本（如果工作副本提交被修改的话）。几乎所有命令（甚至包括 checkout！）都在仓库的提交上操作，将快照和更新工作副本的通用功能交由集中式代码处理。

例如，jj restore（类似于 git restore）可以从任意提交恢复到任意提交，而 jj describe 可以设置任意提交的提交信息（默认为工作副本提交）。

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

你在仓库中执行的所有操作都会被记录，同时记录操作后仓库状态的快照。这意味着你可以轻松恢复到之前的仓库状态，可以逐一撤销操作，甚至可以还原某个特定操作，且该操作不必是最近一次。

冲突可以记录在提交中

如果某个操作产生了冲突，相关冲突信息将被记录在提交中。操作本身会成功执行。你可以稍后再解决这些冲突。

这种设计的一个结果是无需继续被中断的操作。取而代之的是，无论哪个命令引发了冲突，你都使用统一的工作流来解决冲突。这种设计也让 Jujutsu 能够正确地对合并提交进行变基（这是 Git 和 Mercurial 都无法做到的）。

基本冲突解决：

处理冲突：

自动变基

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

全面支持历史重写

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

现状

该工具的功能已相当完善，但一些重要功能（例如对 Git submodule 的支持）尚未完成。还存在若干性能问题。与核心开发者使用方式不同的工作流和配置可能支持不够完善，例如目前没有对基于邮件工作流的原生支持。

目前，所有核心开发者都使用 jj 来开发 jj。我（Martin von Zweigbergk）自 2021 年 1 月初以来几乎完全使用 jj 来开发该项目本身，从未需要重新从源代码克隆（我甚至认为从未需要从备份恢复）。

在 1.0.0 版本之前，将会有工作流变更以及磁盘格式的不向后兼容变更。对于任何格式变更，我们将尽力实现透明升级（正如我们对近期变更所做的那样），或在有需求时提供升级命令或脚本。

相关工作

有若干工具正在尝试解决与 Jujutsu 类似的问题。详见相关工作。

参与贡献

我们欢迎外部贡献，而且有很多事情可以做，所以不要犹豫。如果你想要一个可以帮忙的方向，欢迎随时询问，希望我们能一起找到合适的切入点。

我们为贡献者提供了一些政策和建议。概括来说：

• 非常欢迎提交 bug 报告！
• 合并到 main 分支的每一个提交都会经过代码审查。
• 请遵守行为准则，遵循社区规范。
• 有一份必须同意的 CLA（贡献者许可协议）。重要的是，它不会将版权所有权转让给 Google 或任何其他方；它仅授予我们安全地重新分发和使用你的贡献的权利。