面向 Git 用户的 jujutsu 使用入门

在软件开发领域，版本控制是协作的基石。
Git作为当前主流工具，虽功能强大但设计理念可追溯至2005年，其复杂的命令集和冲突处理机制常令开发者困扰。近年来，新兴工具——比如Jujutsu（jj）和Pijul—— 越来越以其创新设计理念受到关注。

Jujutsu和Pijul代表了版本控制工具的两个革新方向：前者通过兼容性和简化操作降低使用门槛，后者通过数学化模型解决根本痛点。对于Git资深用户，Jujutsu是“即插即用”的效率工具，而Pijul更适合作为长期技术探索。
两者目前均无法完全替代Git，但在特定场景下已展现出显著优势，值得根据团队需求选择性尝试。

jj 是2019 年作为个人爱好项目创建，用 Rust 编写，目前由 Google 资助开发，旨在成为更简单、性能更高、更易于使用的 Git 替代品。

核心创新

1. 工作副本即提交（Working-copy-as-a-commit）

消除Git的暂存区（index）概念，工作目录直接映射为可编辑的提交。修改文件后无需git add，通过jj new即可创建新提交，简化日常操作。

2. 自动重基与变更追踪

修改历史提交后，依赖该提交的后续变更会自动 rebase（如jj edit ），避免Git中手动rebase的繁琐。操作日志完整记录所有变更，支持任意步骤回滚（jj undo）。

3. 多后端支持

默认使用Git仓库作为存储后端，可无缝衔接现有Git项目；同时支持自研存储引擎，未来计划扩展云存储支持（如Google内部系统）。

局限性：

目前还缺乏Git高级特性如子模块、LFS、签名提交和hooks，所以企业级应用存在缺口。

---

从零到生产

安装与初始化

纯 jj 仓库无法被原生 Git 打开，只有 colocate 模式才能与 Git 混合使用

基本命令映射表

核心概念

• 变更集（change）= Git 中的一次 commit，但可随意改写，直到显式 push。
• 工作区永远 clean；你始终处于某个变更集上。
• jj new 创建新的「匿名分支」；jj branch 给变更集贴标签（类似 Git branch）。
• 所有历史都可重写，且不会丢失旧版本（自动保留不可见的「废弃变更集」）。
• 远程协作通过 jj git push/fetch，底层仍是 Git 协议。

日常最佳实践

   

       
# 1. 基于主干创建功能

       
jj new main -m "wip: add login"

       
# 2. 开发、迭代

       
vim foo.rust

       
jj commit -m "parse jwt"

       
# 3. 需要改更早的提交？直接 rebase -i

       
jj rebase -i 'main'

       
# 4. 整理完，推到远端

       
jj git push -c @-

高频技巧

• 快速拆分大提交：
  jj split（交互式选择文件或 hunk 拆成两个变更集）。
• 快速 squash：
  jj squash -r <child> -r <parent> 或 jj squash --into <parent>。
• 撤销任何操作：
  jj op log → 找到误操作的 op → jj op restore <id>（时间机器）。

常见坑与排查

资料

• 官方书：https://github.com/martinvonz/jj/blob/main/docs/tutorial.md
• 实时更新教程：https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html
• 命令补全：在 zsh/bash 里 source <(jj util completion zsh)

速查清单（贴墙用）

   

       
# 新功能

       
jj new main -m "xxx"

       
# 迭代

       
jj commit -m "..."

       
# 整理

       
jj rebase -i 'main'

       
# 推送

       
jj git push -c @-

       
# 回滚

       
jj op restore <prev>

原创作者: somefuture 转载于: https://www.cnblogs.com/somefuture/p/18988670