12 个重大版本

0.20.0 2024年8月7日
0.19.0 2024年7月5日
0.18.0 2024年6月6日
0.15.1 2024年3月7日
0.8.0 2023年7月16日

#334 in 解析器实现

Download history 195/week @ 2024-04-28 247/week @ 2024-05-05 55/week @ 2024-05-12 48/week @ 2024-05-19 35/week @ 2024-05-26 206/week @ 2024-06-02 81/week @ 2024-06-09 56/week @ 2024-06-16 22/week @ 2024-06-23 216/week @ 2024-06-30 105/week @ 2024-07-07 63/week @ 2024-07-14 51/week @ 2024-07-21 67/week @ 2024-07-28 196/week @ 2024-08-04 98/week @ 2024-08-11

每月418次下载
jj-cli 中使用

Apache-2.0

1.5MB
36K SLoC

jujutsu — 一个版本控制系统


Discord

官网   •   安装   •   入门教程

简介

Jujutsu 是一个强大的软件项目版本控制系统。您可以使用它来获取代码副本、跟踪代码更改,并最终发布这些更改供他人查看和使用。它从一开始就被设计得易于使用——无论是新手还是老手,单独从事全新的项目,还是拥有丰富历史和团队的庞大软件项目。

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

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

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

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

  • Mercurial & Sapling:具有许多Mercurial启发式的特性,例如用于选择提交的revset语言。没有显式索引或暂存区。分支类似于Mercurial的“匿名”,因此不需要为每个小的更改想名字。重写历史的原语既强大又简单。输出格式化使用用户可配置的健壮模板语言。

  • Darcs:Jujutsu将其模型中的冲突视为一等对象;它们与提交同样是一等,而像Git这样的替代方案只是将冲突视为文本差异。虽然不如Darcs(它基于补丁的正式化理论,而不是快照)那样严谨,但效果是许多形式的冲突解决可以自动执行和传播。

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

  • 工作副本作为提交:对文件的更改自动记录为正常的提交,并在每次后续更改时进行修改。这种“快照”设计简化了用户界面的数据模型(提交是唯一可见的对象),简化了内部算法,并完全涵盖了Git的stashes或索引/暂存区等功能。

  • 操作日志 & 撤销:Jujutsu记录对仓库执行的每个操作,从提交到拉取再到推送。这使得调试“刚才发生了什么?”或“我是怎么到这里的?”等问题变得更加容易,尤其是当你帮助同事回答他们仓库中的这些问题时!由于一切都被记录下来,你可以轻松地撤销刚才犯的错误。版本控制终于进入了20世纪60年代

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

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

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

    在典型的Git/Mercurial仓库上使用Dropbox和备份工具(如rsync)的基本问题是,它们依赖于本地文件系统操作是原子性、顺序化和非并发的——这在分布式文件系统上或当并发文件复制(用于备份)发生时,锁文件被持有时并不成立。

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

目前的命令行工具称为jj,因为它易于输入和替换(这在英语中很少见)。该项目称为“Jujutsu”,因为它与“jj”相匹配。

柔术系统相对较新,还有很多工作要做。如果您有任何问题,或者想要讨论未来的计划,请加入我们的Discord群组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上就柔术的未来计划进行了演讲!请参阅幻灯片录像

维基百科还包含一个更全面的媒体参考列表

入门

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

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

入门的最佳方式可能是通过教程。还可以查看Git对比,其中包含一个jjgit命令的表格。

随着您对柔术越来越熟悉,以下资源可能有所帮助

如果您正在使用jj的预发布版本,您可能需要查阅预发布(主分支)版本的文档。您也可以通过网站的版本切换器从最新发布版的文档中访问它。版本切换器在您将页面滚动到顶部时,在网站页眉中可见。

特性

兼容Git

柔术的设计旨在使底层数据和存储模型抽象化。今天,它有两个后端——其中之一使用Git仓库进行存储,而另一个是本地存储后端[^native-backend]。

^[本地后端]: 目前几乎没有任何理由使用本地后端。本地后端主要存在是为了确保最终能够添加无法轻易添加到 Git 后端的函数。

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

您甚至可以拥有一个 “本地化”的本地仓库,在其中您可以交替使用 jjgit 命令。

工作副本会自动提交

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

工作副本作为提交意味着命令永远不会因为工作副本是脏的(没有“错误:您对以下文件的本地更改...”)而失败,也不需要使用 git stash。另外,因为工作副本是提交,所以命令在工作副本提交上的工作方式与任何其他提交相同,因此您可以在完成更改之前设置提交信息。

仓库是真相之源泉

在 Jujutsu 中,工作副本的作用比在 Git 中小。命令在开始之前会快照工作副本,然后更新仓库,然后更新工作副本(如果工作副本提交已修改)。几乎所有命令(甚至检出!)都会在仓库的提交上操作,将快照和工作副本的更新功能留给集中式代码。例如,jj restore(类似于 git restore)可以从任何提交恢复到任何提交,并且 jj describe 可以设置任何提交的提交信息(默认为工作副本提交)。

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

您在仓库中执行的所有操作都被记录,包括操作后仓库状态的快照。这意味着您可以轻松地回滚到较早的仓库状态,或者简单地撤销特定的操作(这不一定是最新的操作)。

冲突可以记录在提交中

如果操作产生 冲突,关于这些冲突的信息将记录在提交中。操作将成功。然后您可以稍后解决冲突。这种设计的一个后果是,不需要继续中断的操作。相反,您将获得一个解决冲突的单个工作流程,无论哪个命令引起的。这种设计还允许 Jujutsu 正确地重新基础合并提交(与 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(贡献者许可协议)您必须同意。重要的是,它不会将版权所有权转让给谷歌或其他任何人;它只是赋予我们安全地重新分发和使用您的更改的权利。

强制性的谷歌免责声明

我(马丁·冯·齐格贝格克,[email protected])在2019年底将Jujutsu作为一个爱好项目开始,它已经发展成为我在谷歌的全职项目,有几名谷歌工程师(现在)在各个领域协助开发。话虽如此,这不是一个谷歌产品

许可

Jujutsu作为开源软件提供,根据Apache 2.0许可协议。有关版权和重新分发的详细信息,请参阅LICENSE

依赖项

~17–34MB
~568K SLoC