VSTS中的PR合并错误-合并后，新更改消失了

Question

我正面临一个非常奇怪的情况，其中：

1. 开发人员对某些文件进行了更改。
2. 通过“合并请求”合并了更改。
3. 更改已通过合并删除。

现在，我知道Git合并递归策略的工作原理，并且据我所知，更改应该在合并后仍然存在。

现在，详细信息。主要的提交是：

1. cfff5f5577-这是开发人员进行更改的地方。
2. e2f51c17e7-这是PR合并提交。更改从这里消失了。

因此，这些是PR提交：

这是PR合并提交：

现在，问题的实质是cfff5f5577中的更改没有传播到e2f51c17e7。

据我了解，合并图为：

  +------------ Y -----+ e2f51c17e7
 /                    /
X                    /
 \                  /
  +------ cfff5f5577 

其中Y是PR合并的目标，而X是公共祖先。

Y是e2f51c17e7 ^ 1，它使我们成为462fc3b376：

对于X，我使用merge-base命令生成483b84e708：

因此，最终的合并图是：

           +------ 462fc3b376 --+ e2f51c17e7
          /                    /
483b84e708                    /
          \                  /
           +------ cfff5f5577 

现在，为了使更改显示在合并提交中，应该发生以下情况（据我所知）：

1. 在483b84e708和462fc3b376之间，相关的代码行应保持不变
2. 相关代码行应在483b84e708和cfff5f5577之间更改

如果发生这种情况，更改将传播到e2f51c17e7。

将483b84e708与462fc3b376比较

所以这四行在这里看起来相同。

将483b84e708与cfff5f5577比较

有更改。

将cfff5f5577与e2f51c17e7比较

更改不见了！

将462fc3b376与e2f51c17e7比较

完全一样！

结论

由此我得出结论，自动合并决定取消更改。现在我知道，“超越比较”快照可能无法准确地表示合并图片，因为BC对齐行的方式可能与Git不同。在这种情况下，我会问-如何追溯Git合并过程以了解为什么合并被终止？

这是非常令人不安的，因为这是PR合并提交-我们不能在之前对其进行审查，因为它不是PR提交本身的一部分，因此不能合并到代码库中。我们应该相信它会做正确的事。而且我相信确实如此，因此我在这里完全感到困惑。

任何人都可以解释发生了什么事吗？

Answer 1

愚蠢的我。

当我在本地检查合并时，它立即告诉我存在合并冲突。然后它突然降临在我身上。我们安装了一个合并冲突解决插件。看哪：

开发人员错误地解决了合并冲突。他选择了目标，而不是合并的来源。

案例已关闭。