为什么在 Azure DevOps 构建管道中在拉取请求检查期间引用不同的提交？

Question

在 Azure DevOps 平台中，我的拉取请求具有名为的最后一次提交dbbdc012 ，但构建策略验证指向名为的完全不同的提交3fa5v161

在构建管道执行期间，我希望 Azure DevOps 检查我上次发布的提交的拉取请求。

在本地之后git fetch --all我尝试git checkout 3fa5v16175fcd23f5391fe8880cf8d36cc54e257验证这个提交是什么

它引发了以下错误

致命：引用不是树：3fa5v16175fcd23f5391fe8880cf8d36cc54e257

拉取请求构建管道中会发生什么？

Answer 1

当您设置构建管道来验证拉取请求时，该管道不仅会在拉取请求的分支上构建最新提交，还会首先将该拉取请求与目标分支合并，然后在该结果上运行管道。

\n

例如，如果您有一个主分支main和一个功能分支，并且您从onmy-feature创建了一个拉取请求，那么 Git 历史记录可能如下所示：my-featuremain

\n

                       main\n                        \xe2\x86\x93\n* --- * --- * --- * --- *\n             \\\n              \\--- * --- * --- *\n                               \xe2\x86\x91\n                           my-feature\n

\n

两个分支可能会出现分歧，这意味着最新提交my-feature不再代表合并功能分支后的代码状态。

\n

因此，Azure DevOps 在这里很聪明，它会首先合并您的更改一次，以便测试合并结果的代码状态。所以它有效地做到了这一点：

\n

                       main\n                        \xe2\x86\x93\n* --- * --- * --- * --- * ------ M\n             \\                  /\n              \\--- * --- * --- *\n                               \xe2\x86\x91\n                           my-feature\n

\n

然后管道将在合并提交上运行M。如果您单击构建管道运行中的提交，您可以看到这一点。提交的名称应该类似于\xe2\x80\x9cMerge pull request 123 from my-feature into main\xe2\x80\x9c。

\n

当然，现在，在创建拉取请求后，主分支仍然可以继续进行。因此，有一个功能可以显式重做合并以触发重新评估。您可以从 Pull request\xe2\x80\x99s 菜单访问该选项：

\n

\n

选项 \xe2\x80\x9cRestart merge\xe2\x80\x9d 将要求 Azure DevOps 使用目标分支的最新状态（即main）重做合并。根据结果​​，这可能会导致自动重建，以重新评估最新版本上的管道结果。

\n