在git中合并rebase的优势是什么？

Question

在this article中，作者使用此图解释了变基：

  

Rebase：如果您尚未发布   分支，或已经明确沟通   其他人不应该以他们的工作为基础   在它上面，你有另一种选择。您   可以改变你的分支，而不是   合并，您的提交被替换为   另一个提交与另一个   父，您的分支被移动   那里。

虽然正常合并看起来像这样：

所以，如果你 rebase ，你只是失去了一个历史状态（将来某个时候会被垃圾收集）。 那么，为什么有人想要做一个变基？我在这里缺少什么？

Answer 1

在各种情况下，您可能希望进行变基。

• 您在不同的分支上开发了一部分特征，然后意识到它们实际上是一个线性的思想进展。将它们重新定位到该配置中。

• 您从错误的地方分叉主题。也许这太早了（你需要后来的东西），也许为时已晚（它实际上也适用于以前的版本）。将它移动到正确的位置。 “太迟”的情况实际上无法通过合并修复，因此rebase是至关重要的。

• 您想测试分支与另一个分支的交互，但由于某种原因不想合并。例如，您可能希望查看哪些冲突突然提交，而不是一次性完成。

这里的一般主题是过度合并会使历史变得混乱，如果你最初没有得到你的分支/合并计划，那么变基是一种避免它的方法。太多的合并可能会使人难以跟踪历史记录，也会使使用git-bisect等工具变得更加困难。

还有许多案例促使交互式变革：

• 多次提交应该是一次提交。

• 提交（不是当前提交）应该是多次提交。

• 提交（不是当前提交）在其中或其消息中有错误。

• 应删除提交（不是当前提交）。

• 应该对提交进行重新排序（例如，更加逻辑地流动）。

虽然你在做这些事情时“失去了历史”，但事实是你只想发表干净的工作。如果仍未发布某些内容，则可以对其进行重新定位，以便将其转换为应该提交它的方式。这意味着公共存储库中的最终版本将是合乎逻辑且易于遵循的，而不是保留开发人员在此过程中遇到的任何打嗝。

Answer 2

重新定位允许您以正确的顺序拾取合并。合并背后的理论意味着您不必担心这一点。如果您重新定义，然后按顺序合并新的更改，解决复杂冲突的现实就会变得更容易。

您可能需要阅读Bunny Hopping