Git 的 cherry-pick 和 revert 如何使用三方合并

原文 ↗ Hacker News 讨论 ↗

Git 的 cherry-pick 和 revert 命令被揭示为在底层使用完整的 3 方合并，这解释了它们为何通常比简单的补丁应用更稳健。由此，开发者们进一步讨论了更广泛的 Git 工作流和心智模型——尤其是 merge vs. rebase、squash merge、以及 trunk-based development——以及这些选择如何影响历史清晰度、冲突频率和团队生产力。许多人认为 Git 的强大足以证明其复杂性是合理的，但也强调良好的工具、教程，以及对 Git 底层图结构的理解，是避免痛苦错误的关键。

对文章的总体反应

  • 许多人觉得关于 cherry-pick/revert 使用 3 方合并的解释很清楚；这也印证了他们的直觉：这些操作“比平面补丁更智能”。
  • 有些人惊讶于 cherry-pick 竟然是通过 3 方合并实现的，而 rebase 本质上就是一系列 cherry-pick。
  • 也有人指出了一些小问题，比如链接到 master 分支而不是特定的提交哈希，以便长期保持稳定。

Git 的复杂性、心智模型与 UX

  • 多条评论抱怨 Git 过于复杂，尤其是在修复历史或纠正他人错误时。
  • 也有人认为，这种能力/复杂度对于大型分布式团队是必要的，而问题往往出在薄弱的心智模型上。
  • 几位评论强调，应理解 Git 底层的图/快照模型（提交是完整的树，而不是补丁），而不是死记命令。
  • 友好的可视化 UI 和教程（图形视图、冲突工具、像 learngitbranching 以及“plumber’s guide”风格的文档）被认为非常有帮助。

merge vs rebase vs squash：相互竞争的理念

  • “永远 merge”与“为线性历史而 rebase”两派分歧很大。
  • merge 支持者：
    • 倾向于显式的 merge commit，不（或很少）rebase，并且常把功能分支 squash 成一个提交。
    • 认为 merge 在概念上更简单，冲突更容易处理，而且对共享分支进行 rebase 很危险。
  • rebase 支持者：
    • 频繁 rebase 本地/主题分支，以保持历史线性且便于 bisect；使用交互式 rebase 来整理出干净、原子化的提交。
    • 认为 squash merge 会掩盖混乱的开发过程，并降低历史记录的价值。
  • 也有人指出现实中的权衡：长期存在的分支会让 rebase 很痛苦（反复冲突），而功能分支历史杂乱、又不 squash 的 merge 会让日志显得很吵。

工作流与团队实践

  • 以 trunk 为中心、分支寿命短并配合 feature flag 的开发方式受到赞赏，尤其适用于 SaaS。
  • 也有人只使用非常少的命令子集，避免高级功能以免出错。
  • 对于小团队到底需要多少流程存在争议；有人认为为了“安全”而把流程搞得过于复杂。

关于 3 方合并与冲突的技术说明

  • 有几条评论强调 merge.conflictStyle=diff3 / zdiff3 以及可视化的 3 方工具，是解决冲突的重要辅助。
  • 讨论澄清了 3 方合并早于 Git 出现，而且它不是结合律成立的，这会导致一些令人意外的行为；有人推测更丰富的合并方案（例如“4 方”上下文）可能更好。
  • cherry-pick 和 rebase 被描述为使用 3 方合并来应用差异，这使它们在一些情况下能成功，而朴素的 git apply 风格补丁则可能失败。