Git merge Git merge无法正确识别所有冲突

我遇到了一个奇怪的情况，git合并不能正确识别文件中的所有合并冲突

如果我使用

a

、

b

、

c

等来表示代码块（实际上是100/1000行XML），则会发生以下情况：

原始分支主文件

a
b
c
d
e

更改了功能1分支上的文件

g
b
c
h
i
d
j

母版上更改的文件

a
b
f
d
e

因此，如果我将

master

合并到

feature1

I中，我应该得到以下冲突文件

g
b
<<<<<<< HEAD
c
h
i
=======
f
>>>>>>> master
d
j

g
B
>主人
D
J

（我使用上面提到的文件测试了这个问题，而不是实际的文件，在实际的文件中我得到了正确的冲突文件）

但我从真实文件中得到的是有效的

g
b
c
<<<<<<< HEAD
h
i
=======
f
>>>>>>> master
d
j

g
B
C
>主人
D
J

也就是说，它认为块

h

/

i

和

f

是冲突的，而实际上块

f

是

master

中块

c

的替代品

---

git为什么会这样一团糟？我已经进行了三次检查，我99.9%确信这里的表示是准确的。

您是否也确定以前没有合并和/或恢复？Git真的不喜欢还原合并提交…@CptBartender实际上是的，在正确的提交之前，主机上有一个还原的提交。因此，我有效地合并了3个提交（原始、还原和“正确”提交）。那么，这可能会导致问题？还原的提交本身并不是问题-只有还原合并提交时才是问题。示例：master中有一个文件（注释中不允许换行，所以假设空格是行分隔符）：

ab

。创建一个分支并将其更改为c，然后将其合并为master。然后在master上进行一次恢复提交，这样就返回到

ab

。然后将分支上的文件更改为

xc

，并再次将其合并到master。此时，分支具有

xc

，主分支具有

ab

。从师父的角度来看，这些变化是：

b->c

，

c->b

，

a->x

，所以合并结果是

xb

，而不是

xc

@CptBartender好的，谢谢，很清楚的解释。所以这看起来不像是一个原因。