Git合并冲突疑问：合并main到dev时为何出现冲突？

Git合并的核心逻辑是对比两个分支相对于它们的共同祖先（即你提到的commit C）的修改差异，而非直接对比两个分支的最终文件内容。我们拆解三个关键版本的差异，就能明白冲突的根源：

1. 共同祖先（commit C）的文件内容 #

text in first main
text in second main

2. main分支相对于C的修改 #

main分支在C的基础上，在文件末尾新增了一个空行和一行内容，对应的差异（diff）如下：

diff --git a/file.txt b/file.txt
index xxx..yyy 100644
--- a/file.txt
+++ b/file.txt
@@ -1,2 +1,4 @@
 text in first main
 text in second main
+
+text in fourth main

3. dev分支相对于C的修改 #

dev分支则是完全替换了原文件的所有内容——删除了C里的两行原始内容，换成了一个空行加新内容，对应的差异（diff）如下：

diff --git a/file.txt b/file.txt
index xxx..zzz 100644
--- a/file.txt
+++ b/file.txt
@@ -1,2 +1,2 @@
-text in first main
-text in second main
+
+text in first dev

冲突的本质 #

Git合并时发现：

• dev分支修改了文件的全部原始内容（直接删掉了C里的两行）
• main分支则在原始内容的基础上追加了新内容

这两个修改的范围存在重叠（都涉及原文件的核心内容区域），Git无法自动判断你想要保留哪部分——是保留dev的全新内容，还是保留main的原始内容加新增内容？因此只能抛出冲突，让你手动决策。

你预期的合并结果是内容拼接，但Git不会自动做这种“拼接”判断，因为它无法确认这是你真实的需求——毕竟dev分支的操作看起来是要完全替换原内容，而main是在原内容上追加，这两种操作逻辑互斥，Git没有办法替你做选择。

内容的提问来源于stack exchange，提问作者DumbCoder