Jujutsujj相关项目对比指南git-branchless、Sapling、GitUp 等同类工具横向解析【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjJujutsujj是一款兼容 Git 的版本控制系统官方文档在 docs/related-work.md 中用一页篇幅梳理了六款「试图解决类似问题」的同类工具。本篇技术指南以该文档为核心骨架逐一解析每款工具的定位、核心特性与设计取舍并结合本仓库中的 README.md、docs/sapling-comparison.md、docs/git-comparison.md、docs/working-copy.md、docs/conflicts.md、docs/operation-log.md 等文档以及cli/、lib/源码深入说明 jj 与它们各自的异同。读完本文你将掌握这六款工具各自解决什么问题、与 jj 在「工作副本快照、冲突建模、操作日志、Git 互操作」等核心设计上的差异以及如何结合 jj 的jj git push --change、jj op log、jj workspace等命令对照评估与选型。为什么会有「相关工作」这份清单Jujutsu 并非凭空出现。在 README.md 中作者明确列出它的设计灵感来源Git追求速度与 Git 仓库互操作、Mercurial 与 Saplingrevset 语言、无 index/staging area、匿名分支、历史重写原语、模板化输出、Darcs将冲突作为一等公民对象。相关工具清单正是这一「站在巨人肩膀上」思路的延续——jj与其他工具共享大量目标但用不同的方式实现。从实现层面看这种「借鉴与差异化」贯穿整个代码库revset 解析器位于 lib/src/revset_parser.rs模板系统位于 cli/src/template_parser.rs 与 cli/src/commit_templater.rs冲突存储与合并位于 lib/src/merge.rs 与 lib/src/tree_merge.rs。理解下面每款工具本质上就是理解 jj 在这些关键设计点上「抄了什么、改了什么、另起炉灶了什么」。逐款解析六款同类工具git-branchless在 Git 仓库内实现无分支工作流git-branchless 的定位是在你现有的 Git 仓库内帮助你使用无分支branchless工作流官方文档的描述是「Helps you use a branchless workflow in your Git repo」。它支持匿名分支anonymous branching不需要为每个小改动起分支名撤销undo与 jj 类似提供操作级撤销更快的变基git move将git rebase封装为更快、更顺滑的操作。文档同时指出它「处于重度开发中新功能增长很快」Under heavy development and quickly gaining new features。与 jj 的核心差异git-branchless 构建在 Git 之上必须通过git命令与 hook 机制工作而 jj 从根本上把工作副本建模为一个提交working copy as a commit匿名分支是数据模型的内生属性参见 docs/git-comparison.md 中「no current branch」一节。也就是说jj 不依赖 Git 的「detached HEAD」概念来维持匿名分支——Git 中的 detached HEAD 是一种特殊状态而 jj 中是常态且所有可见提交图的叶子heads都被跟踪不会丢失或被 GC 回收。SaplingMeta 的 Mercurial 深度改造分支Sapling 是 Meta 开发并内部使用的、对 Mercurial 深度改造的 fork。它与 jj 有最多的相似点因为 jj 本身就从 Mercurial 借鉴了大量设计。官方专门为其撰写了一整篇对比文档 docs/sapling-comparison.md核心相似点包括对用户友好的 CLI用 revset 语言选择修订版本对堆叠提交stacked commits的良好支持包括跟踪「匿名 head」没有 Git 那种 detached HEAD 状态、split命令、以及修改提交后自动变基其后代提交用 templates 灵活定制输出。两者的关键差异正是 jj 的招牌设计逐条展开如下。工作副本自动快照 vs 显式提交。使用 Sapling与大多数 VCS 一样用户要明确告诉工具何时创建提交、包含哪些文件而 jj 的每个命令都会自动把工作副本快照成提交见 docs/working-copy.md新文件自动被跟踪、删除的文件自动被取消跟踪。文档列举了三个好处工作副本在每个命令执行时都被有效备份不会有命令因为工作副本有改动而失败不再需要sl shelveCLI 更简单一致因为工作副本被当作普通提交对待。冲突可提交 vs 必须解决后提交。Sapling与大多数 VCS要求用户在提交前解决冲突而 jj 允许把冲突提交进提交里见 docs/conflicts.md。注意提交的是冲突的逻辑表示而不是之类的冲突标记。这带来连锁优势合并冲突不会阻止你检出另一个提交可以想什么时候解决就什么时候解决后代变基永远成功Sapling 也会自动变基但有冲突时会失败合并提交可以被正确变基Sapling 有时会失败冲突本身和冲突解决都可以被变基。撤销操作日志 vs MetaLog。jj 的撤销由 operation log 驱动记录仓库随时间如何变化。Sapling 也有类似机制 MetaLog。两者功能看似相近但 jj 通过jj op log把日志暴露给用户让你能精确指定要回退多远Sapling 的sl debugmetalog只展示单个提交的历史而非整个仓库的历史。此外由于 jj 快照工作副本撤销对工作副本的改动也是可能的例如jj undo一个jj commit后jj diff仍会显示与jj commit之前相同的改动而sl undo一个sl commit后工作副本是干净的。Git 互操作与打磨程度。Sapling 支持从 Git 远程克隆、推送、拉取jj 也支持且 jj 还支持与 Git 仓库共享一个工作副本colocated workspace可以在同一仓库中互换使用jj与git详见 docs/git-compatibility.md。文档也坦承 Sapling 更精致、功能更完整它内置了很棒的 Web UI「Interactive Smartlog」可以拖放提交进行变基等操作。Forge 工作流。Sapling 的sl pr submit --stack可以把一串提交作为独立的 GitHub PR 推送包括设置 base 分支但只支持 GitHub。jj 没有对 GitHub 或其他 forge 的直接集成但有jj git push --change为指定提交自动创建分支——见下文「从源码看jj git push --change」一节。GitUpMac 平台的 Git GUIGitUp 是一款仅限 Mac的 Git GUI。它与 jj 的相似点在于都支持撤销并能把仓库恢复到更早的快照。它由 GitUpKit 库 支撑。它是 GUI 工具与 jj 的 CLI 定位互补。Gitless无 index 概念的 Git 简化接口Gitless 是「为 Git 提供更简单接口」的另一尝试。它与 jj 一样没有 index/staging area 概念。但 Gitless 不会在工作副本改动之间移动切换分支时改动不会随身带走而 jj 由于把工作副本建模为一个提交「工作副本改动随分支移动」是水到渠成的自然结果。用 jj 的体验是工作副本改动永远待在当前提交上你重写提交图时工作副本提交会跟着被自动变基到新位置参见 docs/working-copy.md 中「stale working copy」与自动快照机制。Breezy多存储后端的 VCSBreezy 是另一款 VCS与 jj 的相似点在于支持多种存储后端既有自己的格式也支持.git即把 Git 仓库作为后端之一。jj 在 README.md 中同样强调其「storage-agnostic」设计——把用户界面与版本控制算法从存储系统抽象出来目前只有 Git 后端达到生产可用基于 gitoxide Rust 库但未来可以接入 Mercurial、Breezy 格式乃至 Google 的 Piper/CitC 这类混合系统。GitButler多虚拟分支的 Git 客户端GitButler 是一款 Git 客户端核心特性包括同时操作多个虚拟分支virtual branches、一等公民的冲突处理、操作历史operations history。它的「虚拟分支」概念与 jj 的「匿名分支 bookmark 手动推进」思路不同GitButler 仍以 Git 仓库为事实来源而 jj 把整个仓库状态含书签、各工作区的工作副本提交都记录在自定义存储中。从源码看jj git push --changejj git push --change是相关文档中唯一出现的具体命令示例其行为在 cli/src/commands/git/push.rs 中有完整定义。命令头部注释第 87–93 行说明默认推送指向remote_bookmarks(remoteremote)..的跟踪书签与标签可用--bookmark/--tag推送特定书签或标签用--all推送所有书签和标签用--change根据指定提交的 change ID 生成书签名。--change参数的定义第 209–214 行进一步说明它通过创建书签来推送该提交可重复创建的书签会被自动跟踪生成的默认书签名可用templates.git_push_bookmark设置定制默认为push- change_id.short()。默认模板定义在 cli/src/config/templates.toml 第 30 行git_push_bookmark push- change_id.short()底层实现中create_change_bookmarks函数第 1189 行附近会解析每个变更参数、解析提交模板文本并生成书签名随后推送逻辑会对--change/--named创建的书签做「不移动既有书签」的处理第 393–395 行注释并对--change隐含「允许创建远程书签、不允许删除」第 426–427 行。对应测试见 cli/tests/test_git_push.rs如git push --change 后重复推送、-c -b...混用、以及自定义模板templates.git_push_bookmark的用例。实际使用示例对应相关文档描述# 为某个提交创建书签并推送书签名默认形如 push-change id 短前缀 jj git push --change X --change Y ... # 后续一次性更新整条栈上的所有书签从 main 分叉点到 jj git push -r main..注意与 Git 的差异jj 不会从「跟踪远程书签」自动推导推送目标必须用--remote指定远程仓库名cli/src/commands/git/push.rs 第 104–106 行且不支持一次推送到多个远程。对照维度总结jj 与同类工具的分水岭把六款工具放在 jj 的设计维度上横向对照可以提炼出四条分水岭设计维度jjgit-branchlessSaplingGitUpGitlessBreezyGitButler工作副本自动快照是作为提交否否否否否否冲突可提交/一等公民是否否否否否一等公民冲突操作日志驱动撤销是jj op log有撤销MetaLog快照式撤销否否操作历史无 index/staging area是否否否是否否支持 Git 远程互操作是甚至 colocated是构建于 Git 内是是GUI是是.git 后端是多存储后端是抽象设计否否Mercurial fork否否是否此表依据相关文档、docs/sapling-comparison.md、docs/git-comparison.md、README.md 中可确认的陈述整理「否」表示相关文档未声称具备该能力。与 Git 本身的对比补充语境要真正评估上述工具还需要理解 jj 相对 Git 的概念性差异官方在 docs/git-comparison.md 中做了系统总结其中与本文主题直接相关的几条工作副本自动提交导致 CLI 更简单一致工作副本被当作普通提交没有 index暂存区Git 的 index 既是文件系统信息缓存又被暴露给用户造成 CLI 不必要地复杂。Git 老手可能认为需要 index 才能只提交部分改动但 jj 提供了更直接的命令用jj split把工作副本提交拆成两个用jj squash -i挑选要移入父提交的改动或用jj squash file移动特定文件没有当前分支Git 的「当前分支」是为了防止丢失新提交而必须存在的概念jj 没有对应概念书签手动推进冲突可以提交没有任何命令会因合并冲突而失败冲突被记录进提交之后随时解决。这也让冲突与冲突解决可以被变基覆盖了git rerere的大多数使用场景后代提交自动变基重写提交如jj rebase时所有后代提交自动被变基到新提交之上指向它们的书签与工作副本也会同步更新操作日志取代 reflog操作日志同时记录所有引用的一次性原子更新比 Git 逐引用的 reflog 强大得多并驱动撤销功能单一虚拟根提交像 Mercurial 一样存在一个全零哈希的虚拟根提交作为所有提交的共同祖先消除了 Git 的「unborn branch」状态及相关命令行标志如git rebase --root、git checkout --orphan。这些设计正是 jj 在相关文档中被反复与其他工具比较的底层原因也是评估替代方案时的核心维度。如何进一步研究如果本文激发了你的兴趣建议按以下路径深入本仓库想快速掌握 jj 命令与 Git 命令的对应关系看 docs/git-command-table.md想了解 jj 与 Git 的互操作边界colocated workspace、Git 特性支持矩阵、冲突在 Git 中的表示、change-id header 等看 docs/git-compatibility.md想从测试验证jj git push --change等行为读 cli/tests/test_git_push.rs想了解多工作副本jj workspace add/list/forget这类其他工具不具备的能力看 docs/working-copy.md 的 Workspaces 一节想理解操作日志如何支撑并发安全与撤销看 docs/operation-log.md 与 docs/technical/concurrency.md。一句话总结git-branchless、Sapling、GitUp、Gitless、Breezy、GitButler 各自以「修补 Git」「fork Mercurial」「GUI 化」「简化接口」「多后端」「多虚拟分支」等不同路径接近同一类问题而 jj 的答案是用「工作副本即提交 可提交冲突 操作日志 存储抽象」这套自洽模型从根上重新组织版本控制的基本操作。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考