vsts中的pr合并不正确-合并后新更改消失

我面临着一个非常奇怪的情况,其中:

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

现在,我知道了Git合并递归策略是如何工作的,据我所知,变更应该在合并之后仍然存在。

现在是血淋淋的细节。主要承诺如下:

1. cfff5f5577-这是开发人员进行更改的地方。
2. e2f51c17e7-这是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 merge commit-我们无法查看它 之前 它被合并到代码库中,因为它不是pr提交本身的一部分。我们应该相信它做了正确的事。我相信是的,所以我在这里完全迷惑不解。

有人能解释一下发生了什么事吗?