Git：为什么rebase会导致冲突而merge不会？

Question

我可能没有做对，但谁能向我解释为什么git rebase 会导致冲突，而git merge（同一分支）不会？

据我所知，git rebase 将来自另一个分支的提交放在我在当前分支上所做的提交之前，而 git merge 将这些相同的提交作为补丁应用到我的分支，对吗？ diff 那么不一样吗，尽管可能颠倒了？不知道为什么用其他提交修补我的分支不是问题，而用我的提交修补另一个分支是。

Answer 1

我发现有时我的问题仍然得到了支持。让我为那些不理解当前选择的答案的人解释一下，因为我第一次阅读时肯定没有。

假设您有分支master，提交A、B 和C。

然后从提交 C 创建一个新分支 mybranch。你提交，你得到提交 D 和 E。

与此同时，其他人在 master 上提交了 F 和 G。

master 看起来像这样：A B C F G，而mybranch 看起来像这样：A B C D E。

现在你有两个合并策略：

合并

在mybranch 上，您输入git merge master。它从master 获取所有在mybranch - F 和G 上没有的提交。它首先将F 合并到E 之上（mybranch 的最后一次提交），然后将G 合并到F 之上。

最终结果：A B C D E F G。尽管这些字母的顺序相同，但提交并未按时间顺序完成（或可能尚未完成），因为实际上 F 和 G 已经（或可能已经）在 D 和 @987654350 之前完成@。在这种情况下，您也会看到合并提交。

变基

在mybranch 上，您输入git rebase master。它从master 获取所有在mybranch - F 和G 上没有的提交，并将它们放在当前分支的顶部，使其处于master 当前所处的状态（因为你从master 分支，现在得到所有在master 上完成的提交，因为你分支了）。然后它会接受您的第一次提交 - D - 并将其合并到 G 之上（最后一次提交是在 master 上完成的）。然后它将E 放在D 之上。

最终结果：A B C F G D E。看起来好像从来没有分支被拆分过master，如果 master 是一个连续的工作，因为你有点说“我希望我的分支看起来好像它只是从 master 上拆分出来的，然后我的工作被放在首位的”。这相当于签出master（现在是A B C F G），创建一个新分支mybranch，然后添加你的提交（A B C F G D E）。

为什么 rebase 可能会导致冲突，而 merge 不会。

不赘述，我们只是说可能是在mybranch的E之上合并master的F可能不会导致冲突，但合并mybranch的D 可能位于 master 的 F 之上。这实际上取决于更改了哪些代码，以及它是否是与先前提交兼容的更改。在这两种情况下都可能出现合并冲突。

Answer 2

在变基期间，您将某个分支的所有提交应用到另一个分支之上。其中一个提交可能存在您在后续提交中解决的冲突。因此，merge 操作没有冲突，而 rebase 会导致中间冲突。

另请参阅git rerere，它允许您自动解决已解决的冲突。