文章介绍了Jujutsu版本控制工具中的"megamerge"工作流，指出合并提交并非特殊操作，只是拥有多个父节点的普通提交，适合复杂开发环境或频繁提交小PR的场景。作者认为这一高效工作流未被充分讨论，值得推广。

标题：Jujutsu超级合并工作流：高效开发的秘密武器

本文面向中级Jujutsu用户及对Jujutsu感兴趣的Git用户，介绍一种被称为"超级合并"（megamerge）的高效开发工作流。

【颠覆认知的合并提交】 - 合并提交并非特殊存在，只是包含多个父节点的普通提交 - Jujutsu支持"章鱼合并"（octopus merge），即包含三个及以上父节点的合并 - 这种特性为超级合并工作流奠定了基础

【超级合并的核心逻辑】 开发者创建一个包含所有工作分支的章鱼合并提交（即超级合并），作为开发基础： 1. 包含范围：功能分支、PR待审分支、他人协作分支、环境配置分支等 2. 关键原则：只推送组成超级合并的分支，而非超级合并本身

【四大核心优势】 1. 全局一致性：所有修改基于完整工作集，确保代码交互无冲突 2. 冲突预防：持续合并机制天然规避意外冲突 3. 任务切换：无需版本控制操作即可切换开发任务 4. 分支维护：通过单条命令即可同步所有分支

【操作指南】 1. 创建超级合并： jj new x y z jj commit --message "megamerge"

2. 变更管理：

   • 使用absorb自动归并修改到对应提交
   • 通过squash --interactive交互式合并变更
   • 使用rebase创建新提交分支

3. 配置建议： ```toml [revset-aliases] "closest_merge(to)" = "heads(::to & merges())"

   [aliases] stack = ["rebase", "--after", "trunk()", "--before", "closestmerge(@)", "--revision"] stage = ["stack", "closestmerge(@).. ~ empty()"] restack = ["rebase", "--onto", "trunk()", "--source", "roots(trunk()..) & mutable()"] ```

【注意事项】 - 超级合并仅作为本地开发视图，不应推送到远程仓库 - 使用restack命令可安全更新受控提交 - 该工作流特别适合需要同时处理多任务的复杂开发环境

这种工作流虽然初看复杂，但能显著提升多任务开发效率，值得开发者尝试。

评论内容总结：

1. 对jj工具的积极评价

• 用户认为jj工具非常出色，能有效改善工作流程。

  • "this is great stuff... it is quite fantastic" (评论1)
  • "Git is dead to me... it's not even close" (评论8)

• 社区支持和学习资源丰富，推荐加入Discord。

  • "I also can't recommend the Discord enough" (评论5)

2. 对工作流程的改进建议

• 用户提到文章中的技巧能提升"Megamerge"能力。

  • "Some fantastic tricks in this article... improve my Megamerge game" (评论6)

• 建议结合jjui工具使用，提升用户体验。

  • "jj workflow would be much easier with jjui... best TUI around" (评论6)

3. 对megamerge的讨论

• 用户关注megamerge在分支重叠时的处理方式。

  • "How does the megamerge handle... overlap in changes" (评论4)

• 实际协作中，octopus megamerge可能难以管理冲突，建议采用树状合并。

  • "octopus megamerge hard to collaborate... tree-like megamerge more practical" (评论13)

4. 对jj工具的批评与建议

• 用户指出jj缺少某些功能，如git标签支持和提交日期保留。

  • "I wish Jujutsu supported git tags... preserving commit dates" (评论8)

• 缺乏VS Code的git gutter等效工具，影响部分用户的使用体验。

  • "Doesn’t look like jj has an equivalent in VS Code" (评论11)

5. 对jj工具的历史意义

• 有用户认为jj在当今代理驱动开发时代可能已过时，但赞赏其创新性。
  • "this is all obsolete in the age of agent-driven development... wish jj was around a decade ago" (评论10)

6. 其他正面反馈

• 用户对文章和工具表示赞赏，认为能帮助从git转向jj。
  • "Great post. Thanks for sharing" (评论9)
  • "convinced a few friends to... loosen their death grip on git" (评论3)