在git中合并的rebase有什么优点？

2018-06-17 07:34:58

在这篇文章中，作者解释了这个图表的基础：

alt text http://eagain.net/articles/git-for-computer-scientists/git-history.7.png

Rebase：如果您尚未发布您的分支机构，或者明确表示其他人不应将其工作基于此，则可以选择其他方式。你可以重定义你的分支，而不是合并，你的提交被另一个提交与另一个父代替换，并且你的分支被移动到那里。

而正常的合并会看起来像这样：

alt text http://eagain.net/articles/git-for-computer-scientists/git-history.5.png

所以，如果你变质，你只是失去了一个历史状态（这将在未来的某个时间收集垃圾）。 那么，为什么有人想要做一个rebase呢？ 我在这里错过了什么？

有各种各样的情况，你可能想要rebase。

您在不同的分支上开发了一些功能，然后意识到它们实际上是一个线性的思路。将它们重新配置为该配置。

你从错误的地方分出一个主题。也许它太早（你需要从后面的东西），也许它为时已晚（它实际上也适用于以前的版本）。把它移到正确的地方。 “太晚”的情况实际上不能通过合并来解决，因此重设是至关重要的。

你想测试一个分支与另一个分支的交互，但由于某种原因不想合并。例如，您可能想要查看哪些冲突会立即执行commit-by-commit，而不是全部冲突。

这里的总体主题是过度合并混乱了历史，如果您一开始就没有正确地实施分支/合并计划，那么重组是一种避免它的方法。过多的合并可能会让人难以追踪历史，并且可能会使使用git-bisect等工具变得更加困难。

还有很多情况提示互动式重新分配：

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

一个提交（不是当前的提交）应该是多次提交。

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

一个提交（不是当前的）应该被删除。

提交应该重新排序（例如，更逻辑流动）。

尽管这样做是“失去了历史”，但事实是，你只想发布干净的工作。如果某些东西仍然未发布，可以将其重新布局以便将其转换为您应该实施的方式。这意味着公共存储库中的最终版本将合乎逻辑且易于遵循，而不会妨碍开发人员一路上的任何打嗝。

重新激活可让您按正确顺序选取合并。合并背后的理论意味着你不应该担心这一点。解决复杂冲突的现实变得更容易，如果你重新组合，然后合并新的变化。

你可能想阅读Bunny Hopping

链接地址: http://www.djcxy.com/p/48951.html