到底是什么导致git发生合并冲突？

Question

1）有一个'master'分支，其中包含一个文件

1个

2

3

4

5

2）A从'master'分支并像

1个

2

100

3

4

5

3）B从'master'分支并像

1个

2

3

4

200

5

4）现在，推送变为主机。然后，B也尝试推动。

B会发生什么？有没有合并冲突或没有合并冲突？原因

Answer 1

您的问题暗示了事实并非如此。

具体来说，git push仅推送现有提交。它不合并任何东西，实际上，它甚至从不尝试合并任何东西。

在您的问题中，涉及三个实体（人员和存储库）。A人（我们称她为Alice），B人（我们称其为Bob）和C人（我们称其为Central-Server，他实际上只是一台机器，而不是一个人，尽管这并不重要）。

Alice和Bob都首先从Central-Server获得某个存储库的副本（副本）。它们得到的克隆完全相同（这就是为什么它们被称为“克隆”的原因）：Alice的克隆匹配Bob的克隆匹配Central-Server上的克隆。他们这样做是通过运行git clone <url>在那里<url>点到中央服务器（github上或任何可能），以及它们的git的名称保存离开网址origin（我们会很快再看到这个名字）。

让我们绘制所有三个实体现在都拥有的git commit图（的一部分）的图形：

... - C7 - C8   <-- master

现在，爱丽丝和鲍伯都进行了更改，但是他们进行了不同的更改。爱丽丝承诺更改：

... - C7 - C8 - A   <-- master

然后，爱丽丝奔波git push origin将她的工作推回中央服务器。中央服务器查看她的请求，该请求说“将提交添加A到链的末尾C8，并master指向A”。该操作将新的提交添加到链中，因此被允许，因此中央服务器将“确定”回复给爱丽丝，她就完成了。现在，Central-Server的存储库也看起来与Alice的存储库相同，因为它们A在旧的commit之后都具有新的commit C8，并且master指向commit A（并且commit A指向旧的C8）。

同时Bob进行了更改，还添加了一个新的提交，他的提交图现在看起来像这样：

... - C7 - C8 - B   <-- master

鲍勃不知道爱丽丝已经提交了A，也没有成功将其推送到中央服务器。他去了git push origin，但是这次中央服务器收到一个请求，说“将提交添加B到C8的链的末尾，然后master指向B”。 如果Central-Server这样做，结果将是：

                A
              /
... - C7 - C8 - B   <-- master

也就是说，提交A将保持浮动状态，没有任何指向它的内容。（Branch master会指向B并B指向它C8，而没有指向A。）这通常是一种糟糕的情况，而git拒绝了它，因此Central-Server告诉Bob：

rejected (non-fast-forward)

请注意，没有合并，也没有重新定基。

现在，鲍勃的工作就是进行合并（或重新设置基准）。他应该这样做：

1. 从拥有更新的人那里获取更新。是谁啊 爱丽丝有，中央服务器也有。他只是要求推送到中央服务器，后者告诉鲍勃“不”，因此他不妨从中央服务器获得它。

2. 进行合并（或变基），以解决所有冲突。

3. 重试推送。

如果Bob选择“合并”并正确地进行了合并，则这是他的新提交图：

... - C7 - C8 - A - M   <-- master
              \   /
                B

注意新的合并提交 M。现在，Bob可以重试推送到Central-Server的操作，该服务器当前具有以结尾的链A。这次Central-Server将看到一个master指向的请求M，并且由于M指向A，所以该请求将被允许（现在是“快进”）。

当然，如果Alice（或Dave，Emily或Frank）通过添加新提交A并将其发送回Central-Server 击败Bob ，则Bob将不得不再次合并（或重新设置基准），然后重试。

鲍勃如何管理所有这一切？

鲍勃的选择是合并还是变基。无论哪种方式，Bob都必须解决任何合并冲突-无论使用哪种方法，他都将得到相同的合并冲突。而且，无论哪种情况，他都应该从运行开始：

git fetch origin

（或只是git fetch，它将origin自动使用）。

让我们看一下在重新设置基础或合并之前 Bob的提交图：

                A   <-- origin/master
              /
... - C7 - C8
              \
                B   <-- master

请注意，鲍勃（Bob）master指向提交B，鲍勃（Bob）还有另一件事- origin/master指向爱丽丝（Alice）的提交A。这是做什么的git fetch：它从Central-Server带来了最新版本（或者如果Bob直接从Alice获取，由于她具有相同的提交，则从她那里带来了最新版本），然后为该提交指定了一些标签。标签开头是origin/...因为这是我们允许git clone使用的名称：它只是贴origin/在另一个名称（master在本例中为）之前，以便我们可以区分它们。

如果Bob选择变基，而不是合并，他将他的混帐复制他的承诺B到一个新的承诺B'：

                A       <-- origin/master
              /   \
... - C7 - C8       B'  <-- master
              \
                B

鲍勃的原著会B怎样？答案是：它被抛弃了。如果Bob需要将其保留在存储库中一段时间​​（默认为30天），以防Bob将其保存在Bob的reflog中，但是除非您（或Bob）明确要求git 在此处查看，否则您不会看到这些提交，因此它们似乎已消失。

如果Bob选择合并，他会得到以下信息：

                A       <-- origin/master
              /   \
... - C7 - C8       M   <-- master
              \   /
                B

这是我们上面绘制的同一张图，我们只是将A节点提起，以便可以有一个指向它的箭头（标记为origin/master）。

在这两种情况下，鲍勃现在可以尝试推，因为他的新承诺-无论是B'或M-points回犯A，让他只要求中央服务器来添加新的提交，而不是忘记有或放弃提交A。

合并本身呢？

Git会尝试通过将Alice所做的更改（用添加一行100）与Bob所做的更改（用添加一行200）来帮助Bob 。如果git决定这些更改不会相互冲突，它将保留这两个更改。如果它确定这两个更改影响文件的同一部分，它将给Bob 合并冲突，标记文件的更改区域，并使Bob决定如何组合它们。

鲍勃可以使用自己喜欢的任何方式来获得合并的结果。由Bob负责确保结果正确无误，然后Bob应当将其git告知git add文件的最终版本并git commit提交更改。¹ 如果他用来合并更改的命令是git merge，这将进行合并提交。如果是git rebase这样，它将创建新副本B'。

¹如果Bob选择了git rebase，他只能使用git rebase --continue，它将为他进行提交。对于Bob来说，先做git commit然后再做是安全的git rebase --continue（在git 1.5左右的日子里，在继续进行变基之前，必须手动完成提交部分）。

关于的最后说明 git pull

我鼓励新的git用户开始使用git fetch，然后再做自己的git merge或git rebase。许多文档告诉您从开始git pull，但是我认为这是一个错误。该git pull命令是为了方便起见：它先运行git fetch，然后再运行git merge或git rebase，但这有一些缺陷。不再有任何严重的问题了，但是这些对新用户不利：

1. 它甚至可以在查看更改之前选择合并还是重新设置基准。

2. 默认设置为merge，这对于新用户来说通常是错误的答案，而新用户通常应该重新设置基准。您可以更改默认值，但是新用户不知道提前这样做。您可以添加--rebase以告诉它重新设置基准，但是您可以忘记包含此标志。

3. 它进行的合并是“ foxtrot合并”：它的父提交方向错误。

4. ：相对于手动合并时的言论混淆git pull origin <branch>VS git merge origin/<branch>。（当然，如果要避免foxtrot合并，也不能使用后者，但是无论如何，您可能都应该重新定级。）

5. 如果提供过多的参数（git pull origin master develop），它将使章鱼合并，这是新用户甚至不应该考虑的事情。:-)

6. 它曾经有很多破坏工作的错误案例。我相信它们都是固定的，但是使用git fetch后跟单独的git merge或git rebase始终避免了这些错误。

7. 最后，这里发生了太多的魔术。它应该很方便（对于那些使用git的老手来说很方便），但最终却变得晦涩难懂。