Git Merge 与 Git Rebase

Git merge和rebase 的作用相同——将多个分支合并为一个。虽然最终目标相同，但这两种方法的实现方式却不同。该使用哪种方法呢？

合并或变基是什么意思？

这里有一个示例仓库，它包含两个不同的分支：主分支和功能分支。你想将它们合并在一起。让我们看看这些方法是如何解决这个问题的。

合并

当您运行 时git merge，您的 HEAD 分支将生成一个新的提交，保留每个提交历史记录的祖先。

快速合并是一种不创建提交的合并类型，而是将分支指针更新到最后一次提交。

变基

重新定基将一个分支的更改重写到另一个分支上，而无需创建新的提交。

对于每个在功能分支上而不是在主分支上的提交，都会在主分支之上创建一个新的提交。看起来就像这些提交一直都是在主分支上写的一样。

合并的利与弊

优点：

• 易于使用和理解。
• 维护源分支的原始上下文。
• 源分支上的提交与其他分支的提交是分开的。如果您希望稍后将该功能合并到另一个分支，这将非常有用。
• 保留您的提交历史并保持历史图的语义正确。

缺点：

• 由于多人同时在同一个分支上工作，大量的合并提交可能会严重污染历史记录。仓库的可视化图表可能会变得混乱，无法提供太多信息。它看起来就像一张伦敦地铁图提交！

• 由于合并提交，使用 git bisect 进行调试会变得更加困难。

变基的利与弊

优点：

• 代码历史简化、线性且可读。
• 操作单个提交历史记录比操作带有附加提交的许多单独功能分支的历史记录更容易。
• 简洁明了的提交信息有助于更好地追踪错误或功能引入时间。避免使用 20 多个单行提交来污染历史记录！

缺点：

• 将功能降低到少数提交可能会隐藏上下文。

• 变基功能不适用于拉取请求 (pull request)，因为你无法看到别人做了哪些细微的修改。重写历史记录不利于团队合作！

  与合并相比，重新定基时需要更加小心。

• 处理冲突需要做更多工作。使用 rebase 来保持功能分支更新需要你反复解决类似的冲突。而使用 merging 时，一旦解决了冲突，就万事大吉了。你必须按照冲突发生的顺序解决它们，才能继续 rebase。

选择哪种方法？

当您的团队使用基于功能的工作流程或不熟悉 rebase 时，这git merge是您的正确选择：

• 它允许您保留任何给定功能的提交历史记录，而无需担心覆盖提交和更改历史记录。它可以帮助您避免不必要的git 还原或重置！
• 不同的功能保持独立，不会干扰现有的提交历史。
• 可以帮助您重新集成一个已完成的功能分支。

另一方面，如果你更看重简洁、线性的历史记录，那么这git rebase可能是最合适的。这样可以避免不必要的提交，并使更改更加集中和线性！

如果您错误地重新设定基准并无意中重写历史记录，则可能会导致严重问题，因此请确保您知道自己在做什么！

变基还是合并，你更喜欢哪个？Kolosek 团队更倾向于基于特性的工作流程的合并。

本文最初发表于Kolosek Blog。