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。

现在你有两个 merge 策略:

merge

在 mybranch 上，您键入 git merge master。它从 master 获取您在 mybranch 上没有的所有提交 - F 和 G。它首先将 F merge 到您的 E 之上(mybranch 的最后一次提交)，然后将 G merge 到顶部的 F。

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

rebase

在 mybranch 上，您键入 git rebase master。它从 master 获取您在 mybranch 上没有的所有提交 - F 和 G 并将它们放在当前分支的顶部，将其置于 master 当前所处的状态(因为您从 master 分支并且现在获得在 master< 上完成的所有提交 因为你分支了)。然后它获取您的第一次提交 - D - 并将其 merge 到 G 之上(最后一次提交是在 master 上完成的)。然后它将 E 放在 D 之上。

最终结果:A B C F G D E。看起来好像没有分支从 master 中分离出来，如果 master 是一个连续的工作，因为你有点说“我希望我的分支看起来就像刚刚从 master 中分离出来，然后是我的工作被置于其之上”。这相当于 checkout master(现在是 A B C F G)，创建一个新分支 mybranch，然后添加您的提交(A B C F G D E)。

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

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