为什么git给了我一个“答案”；删除合并冲突“；当双方都被删除时？

我正在将

master

的更新版本合并到我的分支中。在master中，一个文件已被删除，我也删除了该文件。Git给了我以下信息：

Deleted merge conflict for 'Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs':
  {local}: deleted
  {remote}: deleted
Use (m)odified or (d)eleted file, or (a)bort?

---

为什么这是一场冲突？两边都被删除了，所以git应该删除它吗？

首先，我们需要一点背景术语。运行

git merge xyz

时，git标识三个提交：

• 您当前的提交：

  头

  ，“本地”，

  --我们的

  ，等等。我喜欢叫这个L代表左或本地
• 另一个提交：由

  xyz

  标识的提交：“远程”、“其他”、“他们的”，等等。我喜欢把这个叫做R，表示右边或远处
• 第三次提交：L和R在提交中的第一次提交。这是合并基提交

Git计算从合并基到L的差异，以及从合并基到R的第二个差异。这两个差异可以对合并基中存在的文件进行不同的更改

如果

Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs

是合并基提交中的一个文件，并且在两个头中都被删除，则不会发生冲突，也不会发生这种情况

但是，如果合并库中存在

Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs

，并且在一次提交中被重命名（也可能被修改），但在另一次提交中被删除，则将存在重命名/删除冲突。在这种情况下，

git mergetool

在L或R中都找不到

Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs

换句话说，该特定文件将在工作树中删除。但是应该是吗？是否应该从基本提交还原文件？

git mergetool

脚本不知道。它向你提出了这个问题

---

请注意，如果从基本提交中恢复该文件，则仍将保留重命名的文件。这要看你怎么办。

但上面说两个都被删除了，而不是一个被重命名了。在两者都被删除的情况下，“使用修改过的”选项做了什么？我查看了这个答案的来源（我没有使用git mergetool），我不知道他们为什么这样写。如果你说“使用修改的”，它只是抓住了基础版本，这似乎是完全错误的。重命名/删除冲突有一个更普遍的问题：它们在索引中留下的跟踪是不明确的。

git mergetool

shell脚本实际上必须猜测发生了什么。我怀疑大多数超级Git用户都会避免使用这个脚本，这就是为什么它会有这些恼人的bug。