VSTS 中如何确定拉取请求的“相关”工作项？

Question

我最近发现，在查看哪些工作项与不同部署关联时，可以使用链接到拉取请求的工作项。也就是说，我想确保相关的工作项目是准确的。我可以手动链接我的工作项，但在某些情况下，单个挤压合并提交中可能会出现 50 个不同的提交。有很多不同的提交需要手动输入。

我看到 VSTS（Azure Devops）尝试自动添加一些相关的工作项。问题是我不知道这些工作项现在是如何计算的。如下图所示，即使没有检测到代码更改，您也可以拥有关联的工作项。有人可以解释一下吗？根据 Fiddler 的说法，VSTS api 中调用的 API 是：

// POST https://foobar.visualstudio.com/16e07dde-f652-4a64-93f1-3edb3d70d5e1/_apis/git/repositories/c9bd207c-bc6e-4e6c-aba9-8fd6aeb53946/commitsBatch 

{"$top":101,"itemVersion":{"versionOptions":0,"versionType":0,"version":"master"},"compareVersion":{"versionOptions":0,"versionType":0,"version":"users/v-username/140357_TestBranchForFeatureDeployment_ButWithLinks"}}

Answer 1

当您创建拉取请求时，例如从dev到master，它将首先检测这两个分支之间不同的提交。这是commitsbatch您从 Fiddler 跟踪中看到的 api。

对于work items拉取请求中列出的内容，它是与提交关联的请求。检测提交时，也会检测并列出关联的工作项。这些是您在上面分享的屏幕截图中看到的内容。

我想你最关心和困惑的应该是为什么它显示100 提交但仍然说没有文件更改。

据我所知，这似乎是 Azure DevOps PR 的已知限制。请参阅之前向我们报告过的这个帖子。

例如，采用以下分支和提交：

功能/任务-1：

commit e48b5a97d33abf733df656ebc2bf81cedccf7815

功能/任务 2：

commit e48b5a97d33abf733df656ebc2bf81cedccf7815

commit 6a6c2db2c71a584bd07632c7387b7bee3fb32eea

如果feature/task-1和feature/task-2都是 Pull-Requested 进行开发，则feature/task-1合并后，拉取请求 feature/task-2仍将显示提交的更改 e48b5a97d33abf733df656ebc2bf81cedccf7815， 6a6c2db2c71a584bd07632c7387b7bee3fb32eea即使 e48b5a97d33abf733df656ebc2bf81cedccf7815已经合并到开发中。

有了这个限制，提交仍然可以被检测到，但是由于文件更改之前已经被其他分支合并，所以它会说没有文件更改。此外，还会显示与提交关联的工作项。

只需检查一下并确认是否是您所面临的情况即可。如果是，请尝试解决此处提到的我们工程师的问题。

或者你可以在该论坛上提出新的问题，让相应的产品组关注它。