Jujutsujj分歧变更处理完全指南从原理到四种解决策略【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj导读本文是围绕 Jujutsujj中分歧变更divergent changes机制的完整实战指南。Jujutsu 是一款兼容 Git 的版本控制系统它用变更 IDchange ID跟踪一个变更在不同提交间的演进当同一变更 ID 同时对应多个可见提交时就产生了分歧。你将理解分歧产生的底层原理可见性、重写、并发操作学会在jj log中识别分歧标记并掌握放弃、拆分、合并、忽略四种解决策略以及 revset 引用分歧提交的正确姿势最终能从容应对协同开发与多工作区场景中的冲突场景。什么是分歧变更在 术语表 中分歧变更被定义为一个变更change拥有多个可见提交visible commit。当一个变更 ID 同时指向多个可见的提交时它们就是分歧的。Jujutsu 与 Git 的一个核心差异在于引入了两层 ID 抽象见 术语表 与 change提交 IDcommit ID内容寻址的哈希提交内容或元数据一变就变变更 IDchange ID跟踪同一件事的稳定标识重写提交时保持不变。重写提交如改描述、rebase会产生新的提交 ID但变更 ID 通常保持不变旧的提交被隐藏、新的提交可见。正常情况下同一变更 ID 在同一时刻只对应一个可见提交——旧版本成为前驱predecessor被隐藏新提交作为后继successor可见。但当多个提交同时拥有同一变更 ID 且都可见时分歧就发生了。如何在日志中识别分歧默认日志模板会将分歧变更的变更 ID 显示为??后缀底层逻辑见 templates.toml 中的format_short_change_id_with_change_offset与commit.divergent()标签源码位于 commit_templater.rs$ jj log mzvwutvl?? test.userexample.com 2001-02-03 08:05:12 29d07a2d │ a divergent change同时jj log的提交行还会出现(divergent)标签颜色默认配置为洋红色见 colors.toml 中的divergent magenta等键。注意模板设计上让 hidden 优先于 divergent 显示因为隐藏提交不参与也不受分歧影响见 templates.toml 的注释。可见性分歧的底层机制要理解分歧必须先理解可见提交visible commits。按 术语表 的定义可见提交是你在jj log -r all()中看到的提交即从视图view中的匿名头anonymous head可达的提交。可见提交的祖先隐式可见。直观地说可见提交就是一个变更的最新版本。被废弃或重写的提交会停止可见并被标记为 hidden但仍可通过提交 ID 或变更 ID/偏移量组合访问。在代码层面索引模块用ResolvedChangeTargets::is_divergent()精确判定该变更 ID 下可见目标的数量大于 1 即为分歧见 lib/src/index.rs/// Returns true if there are multiple visible targets for this change ID. pub fn is_divergent(self) - bool { self.visible_with_offsets().take(2).count() 1 }而 revset 解析器在遇到变更 ID 是分歧的时会直接抛出DivergentChangeId错误见 lib/src/revset.rs这说明分歧 ID 不能作为符号直接引用——这也是后文四种策略都要用提交 ID 的原因之一。分歧是如何产生的隐藏提交重新变可见正常流程中重写提交后旧版本被隐藏。但一个隐藏提交可能因为以下原因重新变为可见本地新增可见后代例如jj new REV会让REV即使之前是隐藏的也变得可见从远端取回可见后代如果隐藏提交已被推送到远端其他人可能基于它创建新提交。当你 fetch 到这些新提交时它们的可见性会连带让该隐藏提交重新可见成为工作副本jj edit REV会让REV及其所有祖先可见如果此前不可见其他操作例如给隐藏提交添加 bookmark表示你重新开始处理该提交它就会变可见。同一变更被多方同时重写分歧更常见的来源是两个不同的用户或进程修改了同一个变更产生了两个可见的后继提交。典型场景包括协作冲突另一个作者修改了某个分支上的提交而你在本地也修改了同一提交多工作区你在同一仓库的不同工作区对同一变更执行操作并发工具两个程序同时修改仓库。文档给出的经典例子是——你在jj describe的编辑器中撰写提交描述时一个 IDE 集成恰好 fetch 并 rebase 了你正在操作的分支。这与 操作日志机制 密切相关Jujutsu 的操作日志实现了无锁并发并发命令不会损坏仓库但产生的冲突会在后续jj st/jj log中提示。文中举例你一边编辑描述、一边更新内容最终关闭编辑器后命令成功执行但jj log会显示该变更已分歧。另外术语表 将分歧与 bookmark 冲突做了类比变更在本地和远端被分别重写就会进入冲突状态即分歧变更。解决分歧前的准备如何精确引用提交解决分歧的关键前提是必须用提交 IDcommit ID引用分歧提交因为变更 ID 是歧义的。按 revsets 文档一个完整的变更 ID 引用该变更 ID 下的可见提交唯一前缀也可用但使用非唯一前缀或分歧的变更 ID 是错误要引用隐藏提交或分歧变更可以用变更 ID/偏移量语法加上 变更偏移量change offset最近的提交偏移量为 0如xyz/0更早的为xyz/1依此类推。查看分歧提交的完整提交 ID直接运行jj log --no-graph -r divergent()即可——revset 提供了divergent()函数匹配所有 分歧提交。四种解决策略提示以下所有示例中的unwanted-commit-id等占位符请替换为jj log中显示的完整或唯一前缀提交 ID。策略 1放弃其中一个提交Abandon如果其中一个分歧提交明显过时或错误直接放弃它——这是最直接的方案# 用提交 ID 放弃不想要的提交 jj abandon unwanted-commit-id # 可以一次放弃多个 # jj abandon abc def 123 # jj abandon abc::当你知道该保留哪个版本时这是最简单的解法。放弃后该提交变为隐藏剩余提交成为该变更 ID 下唯一的可见提交分歧消除。策略 2生成新的变更 ID如果希望保留两个版本让它们成为两个拥有不同变更 ID 的独立变更可以为其中一个提交生成新变更 IDjj metaedit --update-change-id commit-id--update-change-id选项在 metaedit 命令源码 中定义当指定该标志时会重写提交的变更 ID见 metaedit.rs。这样既保留了双方的内容版本又消除了分歧——两个提交各自成为独立变更的唯一可见提交。策略 3合并提交Squash当你想把两个分歧提交的内容合并到一起时# 将一个提交 squash 进另一个 jj squash --from source-commit-id --into target-commit-id该命令把来源提交的变更合并进目标提交形成单一提交来源提交随后被放弃。这样内容合二为一分歧自然消除。策略 4忽略分歧分歧不是错误。如果它没有造成即时问题可以保持原样如果两个提交都属于不可变历史immutable history忽略可能就是你唯一的选择不过它带来的不便也很明确你无法用变更 ID 无歧义地引用分歧变更。进阶用jj converge自动收敛分歧除了手工四策略当前仓库还提供jj converge命令用于自动化处理分歧。该命令的文档注释见 cli/src/commands/converge.rs说明了其工作方式评估--revisions指定的 revset默认取revsets.converge配置按变更 ID 分组变更 ID 下超过一个修订即为分歧若无分歧则直接成功返回若有多个分歧变更会提示用户选择一个处理核心逻辑来自库层find_divergent_changes()lib/src/converge.rs随后对选中的分歧提交构建截断演化图TruncatedEvolutionGraphlib/src/converge.rs并尝试用启发式自动合并出解决方案提交solution将其作为分歧提交的共同后继见 lib/src/converge.rs若启发式无法得出结论会回退到交互式询问用户可配合--no-interactive在无法自动解决时仅打印警告而不做任何改动用户可能被询问合并修订描述、为解决方案选择父提交、极少数情况下选择作者找到解决方案后新修订会替换该变更 ID 下匹配 revset 的分歧修订分歧修订的后代会被 rebase 到解决方案上指向分歧修订的本地 bookmark 也会更新注意解决方案中可能存在文件冲突无论之前是否已有冲突可通过jj op show -p审查改动、用jj evolog查看变更演化不满意则jj undo回退。jj converge是对四种手工策略的自动化补充适合分歧较多、希望借助启发式与交互提示快速收敛的场景。结语分歧变更是 Jujutsu 基于变更 ID 的并发模型下的自然产物它既不是错误也不代表数据损坏而是同一变更的多个可见版本并存这一事实的显式呈现。理解可见性这一底层概念、熟练使用提交 ID 与变更偏移量精确引用再配合本文的四种解决策略与jj converge自动化工具你就能在协同开发、多工作区与并发工具场景下游刃有余地处理任何分歧。如需进一步了解相关概念可继续阅读 术语表尤其 divergent change 与 visible commits 条目、revsets 参考 与 操作日志说明。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考