在this article，作者用这张图解释了变基：
变基：如果你还没有发布你的 分公司，或已明确沟通 其他人不应以他们的工作为基础 在它上面，你有一个选择。你 可以变基你的分支，而不是 合并时，您的提交被替换为 另一个不同的提交 父级，并且您的分支已移动 在那里。
虽然正常的合并看起来像这样：
所以，如果你rebase，你只是失去了一个历史状态（这将在未来的某个时候被垃圾收集）。 那么，为什么有人想要做一个变基？我在这里错过了什么？
【问题讨论】：
标签： algorithm git version-control dvcs
变基允许您以正确的顺序获取合并。合并背后的理论意味着您不必担心这一点。如果您重新设置基准，然后按顺序合并新的更改，解决复杂冲突的现实会变得更容易。
您可能想阅读Bunny Hopping
【讨论】：
在多种情况下，您可能需要变基。
您在不同的分支上开发了一个功能的几个部分，然后意识到它们实际上是想法的线性发展。将它们重新设置为该配置。
您从错误的地方分叉了一个主题。也许太早了（你需要以后的东西），也许太晚了（它实际上也适用于以前的版本）。将其移动到正确的位置。 “为时已晚”的情况实际上无法通过合并来解决，因此 rebase 至关重要。
您想测试一个分支与另一个分支的交互，但由于某种原因不想合并。例如，您可能想查看逐个提交而不是一次全部出现的冲突。
这里的一般主题是过度合并会使历史变得混乱，如果您一开始没有正确制定分支/合并计划，则重新设置基准是一种避免这种情况的方法。太多的合并会使人类难以跟踪历史，也可能使使用 git-bisect 之类的工具变得更加困难。
还有很多情况会提示交互式变基：
多次提交应该是一次提交。
一次提交（不是当前一次）应该是多次提交。
提交（不是当前提交）或其消息中有错误。
应删除提交（不是当前提交）。
应重新排序提交（例如，以更合乎逻辑的方式进行）。
虽然您在做这些事情时确实“失去了历史”，但现实情况是您只想发布干净的作品。如果某些内容仍未发布，则可以对其进行变基以将其转换为您应该提交它的方式。这意味着公共存储库中的最终版本将合乎逻辑且易于遵循，不会保留开发人员在此过程中遇到的任何问题。
【讨论】：
git log -g ;)