jujutsu 使用指南

最近关注了一个 b 站博主，下划线自然选择下划线lol😅。就是一个 rust 区的博主，然后在他的账号里面我注意到他介绍了 jujutsu，当时他声称是下一代的版本管理工具，直接对位 git 的。

然后今天我在 vibecoding 我的博客网站后台的时候，我的 codex 的最后一次重置卡已经用完了，我想省着留着工作的时候用，于是我去买了火山的 coding plan lite，然后在 opencode 中接入了，一开始使用的 glm5.2，但是 glm5.2 经常容易卡住，于是我换成了 kimi2.7code，但是我没注意到五小时额度（此处有伏笔），我直接让它帮我整理一下博客仓库的文件结构，然后运行到一半，额度用完了☹️，此时我的工作空间已经被搞乱了，虽然我有 git 的习惯，当时也立刻git reset --hard HEAD && git clean -fd但是我还是会担心我的 gitignore 的文件还是会被修改，于是我当时就在考虑有没有比 git 更好的管理工具，后来我去了解了一下jujutsu，虽然不知道能不能解决我上面的问题，但是感觉确实很好用，很有自己的特点。于是便有了这篇博客。（早知道用 mimo 了😭）

jujutsu是在前辈 git、mercurial 等版本管理工具中分别取其长处得到的。

优势

在 20 年前 linus 一个人花了 10 天敲出了 git 的初版原型，彻底改变了软件行业的工作流程，在这 20 年间，linus 和他的团队，对 git 陆陆续续做了很多修改，那为什么还要选择 jujutsu 呢，下面介绍一下jujutsu 的优势。

适应ai 时代

不论是否同意，这个时代的编程方式已经发生了天翻地覆的变化，ai 已经进入了每一个合格的程序员的工作流程中，甚至接管了程序员很多的的工作，和 ai 共同编程就是这个时代的程序员的主旋律。

在日常的工作流程中，我们肯定少不了和让 ai 聚焦需求，并验证 ai 写的代码，在逐步验证的过程中，最好的时间方式就是验证一步就隔离一步，大家肯定都经历过 ai 偷偷改文件删文件，然后美美“跑路”的情况，然而 git 在这样的工作流中就显得有点力不从心了，频繁的 git add 让工作变得繁琐。而且 ai 带来的工作提效往往需要我们测试不同的方案，而 git 如果需要测试不同的方案就需要频繁的清理 worktree，并来回 checkout。

使用

安装

如果有rust环境可以直接

cargo binstall --strategies crate-meta-data jj-cli

如果没有安装 binstall 可以先更新 rust 工具链并安装 binstall

rustup update
cargo install cargo-binstall
#然后再安装
cargo binstall --strategies crate-meta-data jj-cli

binstall是新版本的 rust 推出的二进制安装工具，之前的 cargo install 都是需要从源码编译，下载各种各样的库，花费的时间会比较长，但是 binstall 就会直接下载 GitHub 的编译好的二进制程序直接安装，会快很多。

如果是archlinux 系，还推荐通过 pacman 来安装。执行以下命令

sudo pacman -S jujutsu 

基本命令

假设处于一个真实的工作流中：

首先我们第一步是进入仓库，那么进入仓库分为两种情况，一种是本地创建自己的仓库；另一种是 clone 远程的仓库。

对于创建自己的仓库，类似于 git，可以直接运行

jj git init --colocate .

意思是从 jj 和 git兼容的方式创建库，并不推荐单纯的通过` jj init ` ，因为目前 jj 的功能还不够完善，类似于 tag 还没有，所以从兼容的方式创建是比较中庸的手段。

对于远程仓库，可以直接运行

jj git clone https://github.com/user/name.git
# 或者fetch更新本地库
jj git fetch

对于已经创建好的库，我们可以通过下面指令来查看其状态。

jj status / jj st
# 查看当前的提交状态，类似于git status

jj log
# 查看历史的工作树，类似于git log

下面我聊一些我在使用过程中认识到的点：

听上去有点绕口令，我们在使用 git 的时候，通过 commit 就能直接把当前的工作区“弄干净”，而在 jj 中，虽然也可以用 commit（类似于 git），但是更多还可以使用 describe（desc）这样就是给当前工作区的更改添加一个描述，但是还是处于当前工作区，如果要清空，就需要new，这样的好处是，方便随时对修改的内容进行 desc，随着更改，持续的增删 desc 的内容。

git commit -m "message"
等价于
jj commit -m "message"
等价于
jj describe -m "message" /jj desc -m "message"
jj new

由上面可见，jj 能随时修改正在工作的工作区的 message，同样的，他也可以修改过去已经提交的更改

比如要修改xplzknov(粉色可以直接用 x来代替)，可以直接运行

jj desc -r @-
# 或者
jj desc -r x

然而 git 的话就是先 rebase，再布拉布拉修改。

在 git 中，如果有未完成的代码，同时又想切换分支去测试新的东西，只能先 stash，然后再切换；而 jj 中未提交 @ 是标准变更，支持：改 desc、部分提交、与历史变更合并、直接基于当前半成品切新变更，不用 stash。