Git 的分布式模型在过去二十年里奠定了版本控制的标准，但其以 commit SHA 为核心的寻址机制也带来了显著的认知负担 —— 尤其是在需要频繁重写历史的场景下。开发者常常陷入一种 "严谨性疲劳"：每次 git rebase -i 都需要精确追踪 commit ID 的变化，冲突解决过程中稍有不慎就可能丢失工作上下文，而 git rebase --abort 往往意味着之前所有冲突解决工作的作废。Jujutsu（简称 jj）作为新一代与 Git 兼容的版本控制系统，通过引入变更集（change）概念和自动变基机制，从根本上重构了这一工作流。
Git 疲劳的根源：SHA 寻址与手动历史管理
Git 的核心设计将 commit 视为不可变的快照，通过 SHA-1 哈希唯一标识。这种设计在分布式协作中提供了强大的完整性保证，但也带来了结构性问题：一旦对历史进行任何修改 —— 无论是 commit --amend 还是 rebase—— 所有下游 commit 的 SHA 都会改变。开发者必须手动维护 "变更" 与 "commit ID" 之间的映射关系，这在处理多 commit 的功能分支时尤为痛苦。
更深层的问题在于 Git 的工作区状态与历史操作高度耦合。当你执行 git rebase -i 时，仓库进入一个特殊的 "变基中" 状态，此时的工作区是临时的、不稳定的。如果变基过程中出现大量冲突，或你需要中断工作去处理其他事务，Git 无法自动保存你的进度和意图。正如一位从 Git 迁移到 Jujutsu 的开发者所描述的："如果中途离开，仓库状态无法显示你正在做什么，我经常需要在源码中添加注释来记录 ' 睡前你打算修改 commit X 来做 Y'。"
此外，Git 的冲突处理是二等公民。冲突标记直接写入工作区文件，变基过程中的冲突会阻塞整个流程，迫使你立即解决才能继续。这种 "全有或全无" 的模式在面对复杂重构时极易造成认知过载。
Jujutsu 的变更集模型：Change ID 与自动变基
Jujutsu 的核心创新在于引入了change ID—— 一个与 commit SHA 分离的持久标识符。与 Git 的 commit SHA 在变基后会改变不同，change ID 在 amend、rebase、squash 等操作后保持不变。这意味着你可以随时修改历史中的任意 commit，而无需重新定位下游依赖。
Jujutsu 的工作流设计让开发者永久处于类似 git rebase -i 的状态。当你编辑工作区文件时，jj 会自动将变更提交到当前 change；当你执行 jj new 创建新 change 时，系统会自动处理与上游的关系。更重要的是，jj 支持在任意位置插入或编辑 commit：jj new -A <change-id> 在指定 change 之后创建新节点，jj new -B <change-id> 在之前创建，而 jj edit <change-id> 允许你直接跳转到历史中的任意位置进行修改。
这种设计的威力体现在自动变基机制上。当你在历史中间修改一个 commit 时，jj 会自动变基所有后代 commit，并在日志中显示："Rebased 25 descendant commits onto updated working copy"。与 Git 不同，这一过程不会阻塞你的工作流 —— 即使产生冲突，jj 也会以结构化方式存储这些冲突，允许你稍后处理。
结构化冲突处理：延迟解决与级联冲突管理
Jujutsu 将冲突提升为一等公民。当自动变基产生冲突时，jj 不会将冲突标记写入文件内容，而是将其作为元数据存储。在 jj show 的输出中，冲突以清晰的结构化格式呈现：
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-use crate::miniscript::{satisfy, Legacy, Miniscript, Segwitv0};
+use crate::miniscript::{satisfy, Legacy, Miniscript, Segwitv0};xyz
+++++++ Contents of side #2
use crate::miniscript::{satisfy, Legacy, Miniscript, Segwitv0, ValidationParams};
>>>>>>> Conflict 1 of 1 ends
这种设计的关键优势在于冲突可以级联而不混乱。在 Git 中，如果在变基过程中遇到冲突并产生新的冲突标记，嵌套的冲突标记会导致难以解析的混乱状态。而 jj 的结构化冲突存储避免了这一问题 —— 每个 commit 的冲突状态独立管理，不会因为上游未解决的冲突而污染下游。
更重要的是，你可以延迟解决冲突。在 jj 中，一个带有冲突的 commit 会被标记为 "conflict" 状态，但整个工作流可以继续。你可以先完成其他修改，稍后再通过 jj edit <change-id> 或 jj new -A <change-id> 定位到冲突 commit 进行解决。这种灵活性对于大型重构尤为宝贵 —— 你可以先建立整体结构，再逐步处理细节冲突，而无需一次性承受全部认知负担。
渐进式迁移策略：保持 Git 后端，优化工作流
Jujutsu 的一个关键设计决策是使用 Git 仓库作为存储后端。这意味着你可以在不改变远程仓库、CI/CD 流水线或团队协作方式的前提下采用 jj。jj 在本地维护一个 Git 仓库，将你的 change 映射为 Git commit，并支持通过 jj git push 和 jj git fetch 与远程交互。
基于这一架构，推荐的迁移策略是分阶段采用：
第一阶段：本地开发使用 jj。在日常编码中使用 jj 的自动变基和 change ID 功能管理本地历史。利用 jj describe 随时修改 commit message，jj split 交互式拆分 change，jj squash 合并相邻 change。这一阶段完全在本地进行，不影响团队协作。
第二阶段：代码审查切回 Git。由于 jj 目前的 show 和 diff 功能在审查场景下不如 Git 成熟（例如不支持文件名过滤、不显示 git-notes），建议在需要详细代码审查时临时切回 Git。你可以使用 jj git export 或直接在工作区使用 Git 命令查看历史。
第三阶段：团队推广。当核心开发者熟悉 jj 后，可以逐步在团队中推广。由于 jj 与 Git 完全兼容，团队成员可以按需选择工具，不会互相阻塞。
需要注意的是，jj 目前仍有一些生态工具依赖问题。许多脚本和工具（如 git-annex、aider-chat）假设 Git 仓库结构，在 jj 工作区中可能无法正常工作。此外，jj 缺少 grep 命令，某些 git rev-parse 的等效功能也需要额外查找。这些限制意味着在完全迁移前，保留 Git 作为备用工具是明智的。
实践建议：从 Git 思维到 Change 思维
从 Git 迁移到 Jujutsu 不仅是工具切换，更是思维模式的转变。以下是几个关键实践要点：
1. 用 change ID 替代 commit SHA 进行引用。在 jj 中，你应当习惯使用 klmvpnsr 这样的短 change ID 而非 Git SHA。change ID 在 amend 和 rebase 后保持不变，是你定位工作的可靠锚点。
2. 接受 "永久变基" 的工作流。不要试图 "完成" 变基 —— 在 jj 中，历史始终是可编辑的。当你需要修改历史中的某个 commit 时，直接 jj edit 到该位置，修改后 jj 会自动处理下游。
3. 利用延迟冲突解决管理复杂度。面对复杂重构时，不必立即解决所有冲突。让冲突以结构化形式存在，先完成其他工作，再分批处理冲突。
4. 维护清晰的 change 描述。由于可以随时修改描述，建议在开发过程中使用描述记录当前思考状态 —— 例如以 f 开头标记 fixup commit，在描述中记录待办事项。
Jujutsu 并非要取代 Git 的生态系统，而是提供一个更友好的接口层。它保留了 Git 的分布式优势和存储可靠性，同时通过 change 概念和自动变基机制，将开发者从繁琐的历史管理中解放出来。对于那些在频繁重构、多 commit 功能开发中感到 Git 疲劳的开发者，jj 提供了一个值得认真考虑的选择。
参考来源
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。