Jujutsujj同类工具对比指南从 git-branchless、Sapling 到 GitButler理解下一代版本控制系统的差异化定位【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjJujutsujj是一个与 Git 兼容、既简单又强大的版本控制系统。本篇指南以官方文档中的 Related work相关工作 为核心骨架逐一剖析jj与 git-branchless、Sapling、GitUp、Gitless、Breezy、GitButler 六款同类工具的关系与差异并结合仓库内 Sapling 对比文档、Git 对比文档 以及源码实现帮助你快速建立对版本控制生态的全局认知并回答一个核心问题既然已有这么多类似工具Jujutsu 的设计取舍究竟独特在哪里。引言Jujutsu 在版本控制生态中的位置Jujutsu 的官方文档用一个独立的 Related work 页面列出了六款与它功能相似的现代工具。这些工具共享一个共同的时代背景传统 Git 的暂存区 分支模型 冲突阻塞式工作流让许多开发者感到繁琐于是社区从不同角度尝试重新设计版本控制的交互方式——有的通过包装 Git 提供更友好的界面Gitless、GitButler有的在 Git 之上叠加撤销与匿名分支能力git-branchless有的则是完整重写的独立 VCSSapling、Breezy、Jujutsu 本身。要理解这份列表关键是先抓住 Jujutsu 的三个底层设计支柱它们在 Git 对比文档 中被详细展开工作副本自动提交几乎每个jj命令都会先自动快照工作副本详见 working-copy.md冲突是一等公民冲突可以被记录在提交里而不是阻塞任何操作详见 conflicts.md操作日志operation log驱动撤销每次修改仓库的操作都被记录jj undo等能力都由它支撑详见 operation-log.md。有了这三根支柱再去看每一款同类工具就能立刻看出它们与 Jujutsu 的重合点与分岔点。git-branchless在 Git 之上叠加无分支工作流Helps you use a branchless workflow in your Git repo. Supports anonymous branching, undo, and faster rebase (git move). Under heavy development and quickly gaining new features.git-branchless 的思路与 Jujutsu 高度重合它鼓励用户放弃传统命名分支改用**匿名分支anonymous branching**工作流——即所有提交都叠在一条或多条匿名线上需要时再打标签。这与 Jujutsu 的无当前分支模型几乎同构Jujutsu 的提交图会跟踪所有可见的匿名头anonymous heads提交不会因为没有分支指向而丢失或被垃圾回收参见 glossary.md 中的 Anonymous branch 词条。两者都提供undo。但底层机制完全不同git-branchless 构建在 Git 的 reflog 与 refs 之上Jujutsu 拥有独立的操作日志每个操作对象记录整仓库的 view 快照所有 bookmark、tag、Git ref 的位置可见头集合以及每个工作区的工作副本提交并指向其父操作形成 DAG。在 cli/src/commands/undo.rs 中jj undo的实现UndoArgs非常简单因为撤销一步本质上就是从操作日志里选择前一个操作并恢复其 view。git-branchless 的快速 rebase 功能叫git moveJujutsu 对应的则是jj rebase并且由于自动 rebase 后代提交机制jj rebase之后所有后代提交、指向它们的 bookmark 以及工作副本都会自动跟随更新详见 git-comparison.md。关键差异git-branchless 始终是Git 之上的一层壳它无法改变 Git 本身的数据模型而 Jujutsu 拥有自己的存储层与提交模型尽管默认后端就是 Git 仓库见 git-compatibility.md因此能实现 git-branchless 做不到的能力例如把冲突本身作为提交内容提交。Sapling来自 Meta 的 Mercurial 深度改造分支A heavily modified fork of Mercurial developed and used at Meta. It is compatible with Git, has undo functionality, and a graphical interface.Saplingsl是这份列表中最重量级的对手官方文档专门为它撰写了一篇完整的对比文档Comparison with Sapling。由于 Jujutsu 从 Mercurial 借鉴了大量思想revset 语言、堆叠提交、匿名头、split、amend 后自动 rebase 后代等两者有不少共同点友好的 CLI用于选择修订版本的 revset 语言对堆叠提交的良好支持包括跟踪匿名头没有 Git 的 detached HEAD 状态与split命令通过 templates 灵活定制输出。两者之间的具体差异均来自 sapling-comparison.md维度JujutsujjSaplingsl工作副本每个命令自动快照新文件自动跟踪、删除文件自动取消跟踪需要用户显式提交冲突时命令会失败abort: 1 conflicting file changes需要sl shelve冲突可以提交冲突存储的是冲突的逻辑表示而非标记可随时解决、可继续 rebase提交前必须解决冲突自动 rebase 遇到冲突会失败Undo由操作日志驱动jj op log可直观查看仓库历史并选择回退多远有 MetaLog但sl debugmetalog看起来只展示单个提交的历史而非整仓库历史Git 互操作克隆/推送/拉取之外还支持与 Git 仓库共享同一个工作副本colocated workspace支持 Git 远端互操作但不共享工作副本打磨程度相对更朴素更完善自带交互式 Smartlog 网页 UI可拖拽提交进行 rebase代码托管平台forge工作流无直接集成用jj git push --change为指定提交自动建分支sl pr submit --stack可将提交栈拆成多个 GitHub PR仅支持 GitHub其中工作副本的差异尤其值得展开。Jujutsu 将工作副本视为一个普通提交即因此在 working-copy.md 中可以看到如下推论每次运行命令工作副本都被隐式备份没有任何命令会因为工作副本有改动而失败CLI 更简单一致因为工作副本与其他提交没有任何区别对待。这一差异还延伸到 undojj undo一次jj commit后jj diff会显示与提交前完全相同的改动因为工作副本的改动已被快照进提交撤销操作能还原它而sl undo一次sl commit后工作副本是干净的——改动已经丢进提交里了。GitUpMac 专用的 Git GUI最早实现仓库快照式撤销A Mac-only GUI for Git. Like Jujutsu, supports undo and restoring the repo to an earlier snapshot. Backed by its GitUpKit library.GitUp 的价值在于它证明了把仓库恢复到任意历史快照这一交互模式是可行的它底层由 GitUpKit 库驱动可以让用户随时回到仓库的早期状态。这正是 Jujutsu 操作日志的核心能力jj undo逐条撤销最近的操作jj op revert回退一个并非最新的指定操作jj op restore把整个仓库恢复到某个较早操作时的状态。区别在于GitUp 是 Mac 平台的 GUI 工具其撤销能力建立在 Git 的内部结构之上而 Jujutsu 把操作历史做成了仓库数据模型的一等组成部分——操作日志本身就是一个由操作对象构成的 DAG参考 glossary.md 的 Operation log 词条并且通过顶层选项--at-operation/--at-op可以把任意命令加载到历史中的某个操作视角上执行详见 operation-log.md。Gitless简化 Git 界面但没有暂存区概念的先行者Another attempt at providing a simpler interface for Git. Like Jujutsu, does not have an index/staging area concept.Gitless 与 Jujutsu 的核心共鸣点是取消暂存区index/staging area。Git 对比文档 git-comparison.md 指出暂存区本质上就是HEAD与工作副本之间的一个中间提交因此依赖它的工作流完全可以改用真正的提交来建模——Jujutsu 正是这么做的想要只提交工作副本的一部分改动Git 习惯用git add -p; git commitJujutsu 用jj split把工作副本提交拆成两个想把改动并回父提交Git 用git add -p; git commit --amendJujutsu 用jj squash -i选择要移动的改动或用jj squash file移动指定文件。Gitless 与 Jujutsu 的一个关键分岔点是Gitless 不会在不同分支之间搬动工作副本的改动而 Jujutsu 因为把工作副本本身做成一个提交搬动改动只是 rebase 的自然结果we do simply as a consequence of making the working copy a commit。在 Jujutsu 中从工作副本提交创建新提交、切换基础、合并改动全部统一为对提交图的改写操作这是无暂存区设计能够成立的根本原因。Breezy多存储后端的另一个实践者Another VCS thats similar in that it has multiple storage backends, including its own format as well as .git support.Breezy 与 Jujutsu 的相似点在于多后端存储架构。Jujutsu 的存储层通过 backend 抽象隔离参见 glossary.md 的 Backend 词条目前唯一生产可用的内置提交后端是 Git 后端把提交存进 Git 仓库另外还有用于测试的多款后端同时操作日志、工作副本等也各有可插拔的存储后端。Jujutsu 的 Git 后端能力细节可见 git-compatibility.md包括用jj git init --git-repopath基于已有 Git 仓库或裸仓库创建 jj 仓库用jj git clone URL从远端克隆colocated workspace 模式下jj与git命令可在同一工作副本中混用每次jj命令自动执行 import/export。相比 Breezy自带格式 .git 支持的路线Jujutsu 的 Git 兼容性设计得更深入——它可以在不打断 Git 工具链的前提下与 Git 用户无缝协作。GitButler虚拟分支与多分支并行工作的 Git 客户端A Git client that works with multiple virtual branches simultaneously, first-class conflicts, and operations history.GitButler 是一个 Git 客户端GUI它提出的**虚拟分支virtual branches**概念允许同时并行维护多个逻辑分支配合一等冲突处理与操作历史。这与 Jujutsu 的工作流殊途同归Jujutsu 虽然没有 GUI但在 CLI 层面天然支持多条并行开发线——因为提交图的任何位置都可以长出匿名分支而 bookmarks命名指针只是可选的标签可以随时移动而不影响其指向提交的身份。值得注意的差异GitButler 是构建在 Git 之上的客户端层而 Jujutsu 是完整的 VCS 实现。Jujutsu 的一等冲突意味着冲突可以存在于提交中并被继续 rebase、merge 或 revert详见 conflicts.md而不仅仅是在客户端 UI 里被友好地展示。横向对比一张表看懂六款工具与 Jujutsu 的关系工具类型与 Jujutsu 的共同点与 Jujutsu 的关键差异git-branchlessGit 之上的增强层CLI匿名分支工作流、undo、快速 rebase受限于 Git 数据模型无法提交冲突Sapling独立 VCSMercurial 分支Meta 开发revset、堆叠提交、撤销、Git 兼容需显式提交、冲突阻塞、无 colocated 共享工作副本、有图形界面GitUpMac 专用 Git GUI仓库级撤销与快照恢复平台绑定、构建于 GitUpKit 之上GitlessGit 之上的简化 CLI无暂存区概念不搬动工作副本改动跨分支Breezy独立 VCS多存储后端自有格式 .git走传统提交模型GitButlerGit 客户端GUI多分支并行、一等冲突、操作历史是客户端而非 VCS 本体从源码看 Jujutsu 差异化能力的实现锚点如果你希望验证上述对比中Jujutsu 独有能力的真实性可以在本仓库中找到对应的实现与测试证据自动快照工作副本实现位于 lib/src/local_working_copy.rs配套文档见 working-copy.md测试见 lib/tests/test_local_working_copy.rs一等冲突commit 可携带冲突核心逻辑在 lib/src/conflicts.rs 与 lib/src/merged_tree.rs测试见 lib/tests/test_conflicts.rs冲突标记的快照 多个 diff式物化格式详见 conflicts.md操作日志与 undojj op log、jj undo、jj op restore的命令实现位于 cli/src/commands/operation/ 与 cli/src/commands/undo.rs操作存储抽象见 lib/src/op_store.rs匿名分支 / 可见头跟踪view 对象记录所有可见头相关概念见 glossary.mdview 实现见 lib/src/view.rsGit 后端与 colocated 工作区见 lib/src/git_backend.rs 与 cli/src/commands/git/jj git colocation命令在 cli/src/commands/git/colocation.rs。结语Jujutsu 的差异化定位纵观六款同类工具简化 Git是共同目标但实现的层次不同git-branchless、Gitless、GitButler 是在 Git 之上做增强或包装受制于 Git 的数据模型Sapling、Breezy 是完整重写的 VCS但保留了传统显式提交、冲突阻塞的交互GitUp 则是单平台 GUI。Jujutsu 的独特之处在于它重新设计了数据模型提交可携带冲突、操作日志记录一切、工作副本即提交同时保证与 Git 仓库深度兼容——这使得它既拥有下一代 VCS 的表达能力又能无缝融入现有 Git 协作生态。判断它是否适合你可以从这三个问题入手你是否厌倦了显式git add/git commit与先解决冲突才能继续的阻塞式流程你是否频繁需要撤销/回退仓库状态你的团队是否愿意在一个用 jj 命令操作、底层仍是 Git 仓库的环境里协作如果答案是肯定的那么 Jujutsu 值得你花一个下午用 tutorial.md 实际体验一番。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考