与 git 中的合并相比，rebase 有何优点？
在这篇文章中，作者用这张图解释了变基：
重新设定基准：如果您尚未发布您的 分支机构，或已明确沟通 其他人不应该根据他们的工作 对此，你还有一个选择。你 可以重新设置你的分支的基础，而不是 合并时，您的提交被替换为 另一个不同的提交 父级，并且您的分支已移动 那里。
而正常的合并看起来像这样：
因此，如果您变基，您只会丢失历史状态（将来某个时候会被垃圾收集）。 那么，为什么有人想要进行变基？我在这里错过了什么？
In this article, the author explains rebasing with this diagram:
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.
while a normal merge would have looked like this:
So, if you rebase, you are just losing a history state (which would be garbage collected sometime in the future). So, why would someone want to do a rebase at all? What am I missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在多种情况下您可能需要变基。
您在不同的分支上开发功能的几个部分，然后意识到它们实际上是想法的线性进展。将它们重新调整为该配置。
您从错误的地方分叉了一个主题。也许太早了（你需要稍后的东西），也许太晚了（它实际上也适用于以前的版本）。将其移动到正确的位置。 “太晚”的情况实际上无法通过合并来修复，因此变基至关重要。
您想要测试一个分支与另一个分支的交互，但由于某种原因不想合并。例如，您可能希望逐个提交地查看出现的冲突，而不是一次全部出现。
这里的总体主题是，过度合并会使历史变得混乱，如果您一开始没有正确制定分支/合并计划，则变基是避免这种情况的一种方法。太多的合并会让人们很难跟踪历史，也会让像 git-bisect 这样的工具更难使用。
还有许多情况会提示交互式变基：
多次提交应该是一次提交。
一次提交（不是当前的）应该是多次提交。
提交（不是当前提交）或其消息中有错误。
应该删除一个提交（不是当前的）。
提交应该重新排序（例如，更符合逻辑地流动）。
虽然做这些事情确实会“失去历史”，但现实是你只想发布干净的作品。如果某些内容仍未发布，可以对其进行变基，以便将其转换为您应该提交的方式。这意味着公共存储库中的最终版本将是合乎逻辑且易于遵循的，不会保留开发人员在此过程中遇到的任何问题。
There are variety of situations in which you might want to rebase.
You develop a few parts of a feature on separate branches, then realize they're in reality a linear progression of ideas. Rebase them into that configuration.
You fork a topic from the wrong place. Maybe it's too early (you need something from later), maybe it's too late (it actually applies to previous versions as well). Move it to the right place. The "too late" case actually can't be fixed by a merge, so rebase is critical.
You want to test the interaction of a branch with another branch, but for some reason don't want to merge. For example, you might want to see what conflicts crop up commit-by-commit, instead of all at once.
The general theme here is that excessive merging clutters up the history, and rebasing is a way to avoid it if you didn't get your branch/merge plan right at first. Too many merges can make it hard for a human to follow the history, and also can make it harder to use tools like
git-bisect.There are also all the many cases which prompt an interactive rebase:
Multiple commits should've been one commit.
A commit (not the current one) should've been multiple commits.
A commit (not the current one) had a mistake in it or its message.
A commit (not the current one) should be removed.
Commits should be reordered (e.g. to flow more logically).
While it's true that you "lose history" doing these things, the reality is that you want to only publish clean work. If something is still unpublished, it's okay to rebase it in order to transform it to the way you should have committed it. This means that the final version in the public repository will be logical and easy to follow, not preserving any of the hiccups a developer had along the way.
变基允许您以正确的顺序进行合并。合并背后的理论意味着您不必担心这一点。如果您重新设置基础，然后按顺序合并新的更改，那么解决复杂冲突的现实会变得更容易。
您可能想阅读 兔子跳跃
Rebasing allows you to pick up merges in the proper order. The theory behind merging means you shouldn't have to worry about that. The reality of resolving complicated conflicts gets easier if you rebase, then merge new changes in order.
You might want to read up on Bunny Hopping