algorithm - 与 git 中的 merge 相比，rebase 有什么优势？

Question

在this article ，作者用这张图解释了 rebase :

Rebase: If you have not yet published your branch, or have clearly communicated that others should not base their work on it, you have an alternative. You can rebase your branch, where instead of merging, your commit is replaced by another commit with a different parent, and your branch is moved there.

虽然正常的 merge 看起来像这样:

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

Answer 1

在多种情况下您可能想要 rebase 。

• 您在不同的分支上开发功能的几个部分，然后意识到它们实际上是想法的线性进展。将它们重新设置为该配置。

• 您从错误的地方 fork 了一个主题。也许为时过早(您需要稍后的东西)，也许为时已晚(它实际上也适用于以前的版本)。将其移动到正确的位置。 “为时已晚”的情况实际上无法通过 merge 来解决，因此 rebase 至关重要。

• 您想测试一个分支与另一个分支的交互，但出于某种原因不想 merge 。例如，您可能希望逐个提交地查看哪些冲突突然出现，而不是一次全部出现。

这里的总体主题是过度 merge 会使历史变得困惑，如果您一开始没有正确制定分支/merge 计划，则 rebase 是一种避免这种情况的方法。太多的 merge 会让人们难以追踪历史，也会让像 git-bisect 这样的工具变得更难使用。

还有很多情况会提示交互式 rebase :

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

• 一次提交(不是当前提交)应该是多次提交。

• 提交(不是当前提交)或其消息有错误。

• 应删除提交(不是当前提交)。

• 应重新排序提交(例如，使流程更符合逻辑)。

虽然您在做这些事情时确实“失去了历史”，但实际情况是您只想发布干净的作品。如果某些内容仍未发布，可以对其进行 rebase 以将其转换为您应该提交它的方式。这意味着公共(public)存储库中的最终版本将合乎逻辑且易于遵循，不会保留开发人员在此过程中遇到的任何问题。