1. 什么是

   • 必要和充分的条件，和/或

   • 所有案例或一些常见案例

   这可能会导致git merge报告合并冲突？

   如何git merge判断一行或几行是否包含 合并冲突？

2. 例如，我有时会看到类似以下的情况，其中Part 1 or Part 2是空的

   <<<<<<< HEAD
   (Part 1)
   =======
   (Part 2)
   >>>>>>> some-other-branch
   

   对我来说，它看起来不太可能发生合并冲突。那么有哪些可能的原因 像这样的情况有合并冲突吗？

3. 比较报告的合并冲突git merge和 报告的差异git diff, 是否正确

   • 所报告的差异git diff可能不一定位于报告的合并冲突的位置git merge, and

   • 报告的合并冲突git merge可能不一定位于报告差异的地方git diff?

Thanks.

完整、正确的答案由多个部分组成。首先，我们必须首先进行正常的三向合并（在 Git 中需要使用-s recursive or -s resolve，如果使用-s recursive，找到一个合并基础和另外两个提交）。但是，您可能想直接跳到第三部分。

正常三向合并所需的元素

To do 任何合并， 你需要：

• a merge base commit B,¹
• 当前提交L（左侧，又名HEAD） 具有B作为一个祖先，
• 另一个提交R也有B作为一个祖先。

由于“是祖先”允许提交图中的节点相等（从技术上讲，它是前驱或等于≼比较），因此可以有B = L and/or B = R。然而，如果是这种情况，那么就永远不会合并required，如果你确实强制合并（使用git merge --no-ff-这意味着B = L and L ≺ R;两种非强制情况是“快进”实际上不是合并和“没有要合并”错误）不会有合并冲突。因此，我们不妨假设合并基数先于合并的两侧。

¹Using --allow-unrelated-histories, you can have Git substitute in the empty tree for an actual base commit, if L and R have no lowest common ancestor nodes. This, however, causes all identified files to be add/add conflicts.

给定合并，冲突所需的元素

接下来，获取某些文件中的冲突path，您需要我所说的“高级”冲突或“低级”冲突（或两者兼而有之）。要实现这一点，Git 必须identify（即匹配在一起）文件B, L, and R。由于能够添加新文件、重命名文件和删除文件，因此不需要文件具有一样的名字在所有三个提交中。尤其：

• If path P exists in all three of B, L, and R, the three files with path P are identified together. (That is, there's a path P_B, such as path/to/foo.txt, that has a matching P_L