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

Question

在 Azure DevOps 平台中，我的 Pull Request 最后一次提交名为

dbbdc012

但是构建策略验证指向一个完全不同的名为

3fa5v161

的提交

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

在本地

git fetch --all

之后我尝试

git checkout 3fa5v16175fcd23f5391fe8880cf8d36cc54e257

以验证这个提交是什么

引发了以下错误

致命：引用不是树：3fa5v16175fcd23f5391fe8880cf8d36cc54e257

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

Answer 1

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

例如如果你有一个主分支

main

和一个功能分支

my-feature

并且你创建了一个从

my-feature

到

main

的 pull request，那么 Git 历史可能看起来像这样：

                       main
                        ↓
* --- * --- * --- * --- *
             \
              \--- * --- * --- *
                               ↑
                           my-feature

两个分支都可能发生分歧，这意味着

my-feature

上的最新提交不再代表合并功能分支后的代码状态。

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

                       main
                        ↓
* --- * --- * --- * --- * ------ M
             \                  /
              \--- * --- * --- *
                               ↑
                           my-feature

然后管道将在合并提交上运行

M

。您可以看到，如果您单击构建管道运行中的提交。提交的名称应该类似于“将拉取请求 123 从我的功能合并到 main”.

现在，当然，在您创建拉取请求后，主分支仍然可以进行。所以有一个功能可以显式redo合并以触发重新评估。您可以从拉取请求的菜单中访问该选项：

“重新启动合并”选项将要求 Azure DevOps 重新合并目标分支的最新状态（即

main

）。根据结果，这可能会导致自动重建，以重新评估最新版本的管道结果。