在现代软件开发中，大型项目经常面临需要同时合并数十个功能分支的场景。传统的 Git 工作流在处理此类情况时往往会产生大量的 merge 提交，导致提交历史变得混乱且难以追溯。Jujutsu 作为新兴的版本控制系统，通过其强大的图操作能力，提供了一种名为 megamerge 的创新工作流，能够在单个工作目录中并行管理多个分支，同时保持清晰的线性历史。
megamerge 的核心设计理念
megamerge 工作流的核心思想是将一个多父提交作为 “工作枢纽”，所有并行开发的任务都在这个合并提交或其后续提交上进行。当某个任务完成后，将其变更压缩（squash）回对应的父提交，从而保持每个父分支的历史纯净性。这种设计特别适合那些需要同时推进多个功能特性、但又希望最终合并结果保持线性可读的团队。
与传统的分支切换模式不同，megamerge 允许开发者在同一个工作目录中同时激活所有需要整合的代码流。这意味着一旦完成了 megamerge 的初始设置，开发者就可以在同一份代码基础上同时测试和调试多个功能的交互，而无需频繁切换分支或使用 stash 来保存临时更改。这种工作方式极大地提升了开发效率，尤其是在需要验证多个功能之间集成效果的场景中。
创建多父合并提交
在 Jujutsu 中创建多父合并提交非常直观。使用jj new命令时，可以同时指定多个父提交作为参数。例如，如果当前有三个独立的开发分支分别对应变更 ID 为c、n和x，则可以通过执行jj new c n x来创建一个包含这三个父提交的合并工作区。此时 Jujutsu 会自动将这三个分支的代码状态合并到工作目录中，形成一个统一的基线。
创建合并提交后，应当为其设置有意义的描述信息以便于识别。建议使用类似[merge]的前缀来标记这是一个 megamerge 提交。同样的，对于工作进程中的暂存提交，可以使用[wip]作为标记。这种命名约定有助于在后续操作中快速定位和识别特定的提交。整个 megamerge 的生命周期内，所有相关的代码修改都应当发生在这个合并提交或者它的后续提交之上，这样可以确保所有的变更都能够被正确地追踪和管理。
变更的压缩回填与分支管理
当某个功能分支的工作完成并需要将其合并回主分支时，Jujutsu 提供了jj squash命令来完成这一操作。具体做法是使用jj squash --into n --keep-emptied命令将当前工作区的变更压缩到指定的目标父提交n中。这里的n代表该功能分支最新的一个提交。--keep-emptied参数的作用是保留当前工作区的空提交，以便继续在该 megamerge 上进行其他工作。
这种设计的关键优势在于它保持了父分支的线性历史。每个功能分支的提交在最终合并时会被压缩为单个原子性变更，类似于 Git 的 squash merge，但整个过程更加可控且不会产生额外的 merge 提交。团队可以根据需要决定何时将某个功能分支的变更正式合并到主分支，而无需等待其他功能分支准备就绪。
动态添加与移除工作流
在实际开发过程中，经常会遇到需要在 megamerge 中动态添加新的功能分支的情况。Jujutsu 通过jj rebase命令的灵活语法支持这一操作。首先使用jj new m创建一个新的提交作为新的工作流基础，其中m指向共同祖先（比如 main 分支）。然后执行jj rebase -s orl -d "all:orl-" -d wtm来将现有的 megamerge 及其所有后继提交变基到包括原有父提交和新添加的工作流之上。
这个命令中的all:orl-表示所有现有的父提交，而wtm则代表新添加的工作流分支。通过这种语法，Jujutsu 能够自动处理复杂的图重写逻辑，包括保留所有后代提交的继承关系。这在传统的 Git 中是一个相当复杂的操作，但在 Jujutsu 中只需一条命令即可完成。
同样地，如果需要从 megamerge 中移除某个工作流，可以使用集合差运算来实现。通过jj rebase -s orl -d "all:orl- ~ qkl"这样的命令，可以从 megamerge 中排除特定的父提交qkl。其中的~运算符执行集合差操作，返回在all:orl-中但不在qkl中的元素。
冲突处理与安全保障
大型合并不可避免地会遇到代码冲突问题。Jujutsu 在这方面提供了独特的优势 —— 它保留了完整的冲突元数据，使得冲突解决过程更加透明和可追溯。当在 megamerge 中移动变更时，如果目标位置与源位置存在冲突，Jujutsu 会在相应的提交上标记冲突状态，并提供清晰的 conflict markers 用于手动解决。
一个重要的实践建议是在每次将变更压缩回父分支后，都应当立即在 megamerge 上测试集成状态是否正常。这有助于及早发现因合并导致的回归问题。由于 Jujutsu 的undo功能可以回滚任何操作，开发者在探索不同合并策略时无需担心会造成不可逆的破坏，可以大胆尝试直到找到最佳的整合方案。
对于需要长期维护的大型项目，建议在代码仓库中维护一份 megamerge 工作流的文档说明，详细记录团队约定的命名规范、操作流程和回滚策略。这有助于新成员快速上手，同时确保整个团队的操作一致性。
适用场景与实践建议
megamerge 工作流最适合以下场景：需要并行开发多个相关功能的团队、单个 PR 包含大量提交的代码审查流程、以及需要频繁进行集成测试的项目。它使得开发者能够在本地环境中轻松构建完整的集成环境，而无需等待所有功能分支都推送到远程仓库。
对于希望采用此工作流的团队，建议从少量分支的简单场景开始实践，逐步熟悉 Jujutsu 的图操作语法后再扩展到更复杂的多分支场景。由于 Jujutsu 仍处于实验阶段，日常使用中可能会遇到一些边界情况的 bug，但其在版本控制工作流上的创新设计已经展现出巨大的潜力。
资料来源：本文参考了 Benjamin Tan 关于 Jujutsu 合并工作流的详细教程（ofcr.se）以及 fnordig.de 上的 Mega-merges 技术笔记。