Git：为什么重基会导致冲突，而合并不会？

我可能做得不对，但有谁能解释一下为什么

git-rebase

会导致冲突，而

git-merge

（同一分支）不会

---

因为据我所知，

git-rebase

将来自另一个分支的提交放在我对当前分支所做的提交之前，而

git-merge

将这些提交作为补丁应用于我的分支，对吗？那么差异是否不相同，尽管可能相反？不确定为什么用其他提交修补我的分支不是问题，而用我的提交修补其他分支是问题。

在重新基址期间，将某个分支的所有提交应用到另一个分支上。其中一个提交可能存在冲突，您可以在后续提交中解决该冲突。因此，合并操作没有冲突，而重基会导致中间冲突

---

另请参阅允许您自动解决已解决的冲突的部分。

我发现有时我的问题仍在获得投票权。让我为那些不理解当前所选答案的人解释一下，因为我第一次阅读时肯定不理解

假设您的分支

master

具有提交

A

、

B

和

C

然后从提交

C

创建一个新分支

mybranch

。您提交，然后您将获得提交

D

和

E

同时，其他人在主机上提交

F

和

G

master

然后看起来像这样：

abcfg

，而

mybranch

看起来像这样：

abcde

现在有两种合并策略：

合并 在

mybranch

上，键入

git merge master

。它从

master

获取您在

mybranch

-

F

和

G

上没有的所有提交。它首先将

F

合并到

E

（上次提交

mybranch

）上，然后将

G

合并到

F

上

最终结果：

A B C D E F G

。尽管这些字母的顺序相同，但提交没有按时间顺序进行（或可能没有进行），因为实际上

F

和

G

在

D

和

E

之前就已经（或可能已经）进行了。在本例中，您也将看到合并提交

重基 在

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

（现在

abcfg

），创建一个新分支

mybranch

，然后添加提交（

abcfgde

）

为什么重新基础可能会导致冲突，而合并不会。

---

在不深入讨论细节的情况下，我们可以这样说，将

master

的

F

合并到

mybranch

的

E

上可能不会导致冲突，但将

mybranch

的

D

合并到

master

的

F

上可能会导致冲突。这实际上取决于更改了哪个代码n如果是与上一次提交兼容的更改。在这两种情况下都可能出现合并冲突。

我理解您的意思，但我仍然没有完全理解。假设我的分支a有提交a、b和c。然后我用提交d和e创建分支b。提交f在分支a上进行。重新基（在分支b上时）合并将导致：a、b、c、f、d、e；合并将导致：a、b、c、d、e、f。现在，如果提交f是在分支a上提交c的基础上创建的，那么提交f究竟如何才能与提交c产生合并冲突？@minitauros（1）合并将导致两个分支连接：一个与a、b、c、f连接，另一个与a、b、c、d、e连接，而不是线性历史。（2）如果分支A上的commit F没有引入冲突，那么我看不出它在重定基址时如何引入冲突（如果您有更详细的示例，那就太好了）但是，如果D与F冲突，而E修复了该冲突，则重基将重播该冲突，而合并则不会。好吧，那么，感谢这里的解释！确实澄清了一点。不幸的是，我不再提供该示例（因为我已经修复了它），但如果我再次遇到同样的问题，我会用更多的信息更新这篇文章：）。现在我认为这个答案足够好了，谢谢！