git合并后源分支和目标分支会发生什么？

Question

当我执行git checkout branch1然后是git merge branch2去合并两个分支时，似乎branch2简单地覆盖了branch1。这种情况是否应该发生？

编辑：

合并前

• branch1 = readme.txt（Hello World！）
• branch2 = readme.txt（Hello 2！）

合并后

• branch1 = readme.txt（Hello 2！）

老实说，我不确定合并技术上应该做什么。

- LightBox

---

这要看情况。请提供更多细节。 - Paŭlo Ebermann

它应该做的是将自从两个分支分歧以来，你在分支2上提交的所有内容应用到分支1上。请具体说明合并时会发生什么。 - Philipp

编辑：我想合并是指合并的文件，而不是合并文件的内容。 - LightBox

Answer 1

当将一个分支合并到另一个分支时，git merge会将两个分支自从分岔后的所有提交应用于被合并的目标分支。你可以认为它形成了一个新的头部，其中包含了两个分支合在一起的最新状态。如果你在一个分支中更改了文件，并将其合并回其父分支，那么这些更改将被应用于该分支当前状态之上。如果两个文件在同一个位置都有更改，则合并可能无法解决此问题，您需要进行干预。通常，您只会得到来自两个分支的最新工作。

在你的例子中，你在branch2中所做的更改已经合并到branch1中了。这似乎将文本更改为"Hello 2!"。

关于此，git-merge手册有以下说明：

  

假设存在以下历史记录，并且当前分支是“master”：

          A---B---C topic
         /
    D---E---F---G master

然后，“git merge topic”会重播自主题分支与主分支（即E）分叉以来所做的更改，直到其当前提交（C）位于主分支之上，并将结果记录在一个新的提交中，其中包括两个父提交的名称和用户对更改的日志消息。

          A---B---C topic
         /         \
    D---E---F---G---H master

简言之，这是“merge”正确的操作方式。

- Will

Answer 2

如果在 branch1 和 branch2 中的 readme.txt 发生了分歧，合并这些分支将导致该文件处于 冲突 状态。冲突状态由两个不同版本的内容存在于文件中，使用冲突标记来标识：

<<<<<<< HEAD:hello.txt
Hello world!
=======
Hello 2!
>>>>>>> 01234567890abcdef:hello.txt

一次合并如果出现冲突将不会自动提交。取而代之的是，会显示一条消息指导您手动解决冲突并展示如何提交更改：

CONFLICT (content): Merge conflict in <file>
Automatic merge failed; fix conflicts and then commit the result.

正如 Nevik Rehnel 指出 的那样，如果文件在分支中没有发生分歧，而只是从共享的公共内容 (Hello world!) 修改为新内容 (Hello 2!)，那么就不会有冲突，合并操作将仅应用更改。换句话说，合并 不保证合并文件内容，而是合并与共同基础相比的更改。

- user4815162342

---

不一定。如果分支2包含分支1的更改（或者说是与该文件相关的更改），Git可以识别出分支2中的所有更改都优先于其他更改（即共同历史）。在这种情况下，不会创建冲突，因为显然分支2的更改是后来进行的。 - Nevik Rehnel

我本以为会有冲突，但正如Bevik Rehnel所暗示的那样，并没有发生冲突。我该如何模拟一个冲突？ - LightBox

@Okyekyein，你可以通过在两个分支中同时编辑文件的同一部分来创建冲突。所以在第一个分支中将文本更改为"Hello1"或其他内容。然后当你合并它们时，git将无法确定使用哪个更改，并会要求你手动解决冲突。（如果在你的平台上正确设置了git mergetool，你可以很好地完成这个任务。） - Will

@NevikRehnel 很好的观点；我现在已经更新了答案，涵盖了这种情况，并删除了OP误解合并结果的说法。 - user4815162342