我们遇到的情况是，我们的工作项已包含在许多内部版本中，without sufficient documentation我似乎无法弄清楚为什么。想知道这里是否有人可以照亮它。
示例场景是
- 我们运行“发布流”分支策略（就像MS描述的那样，它们对Azure DevOps有用）
- 错误30368已链接到功能分支，并通过PR 2991返回主服务器并提交cb9120d0。
- 为此已准备好所有与PR和Branch的链接，因此PR和主提交均正确显示了指向工作项的链接
- 我们从master创建发行分支，并将30368包含在v2.97.0构建管道中，并（正确地）链接到该构建的“集成于构建中”
- 版本1已创建
- 然后，在发布测试期间v2.97.0中存在一个错误（与Bug 20368无关），因此我们Cherry在发布分支中选择了具有修复程序的主提交（按照发布流程指南）。
- 我想知道这个Cherry Pick是导致我稍后描述的问题的原因
- 当然，该工作项未包含在v2.97.0的第二个版本中，只有具有相关修补程序的工作项才包含在内
- 版本2已创建
- 到目前为止，一切都很好。 v2.97.0版本是从Build 2部署的，所有链接都是正确的
- 现在，我们从master分支开始进行v2.98发行，发行管道将进行另一次构建。
- 出于某种原因，它确定30368也应链接到此版本，并在v2.98版本中添加“集成在版本中”？
我发现的唯一其他线索是与构建链接的提交有关。在这里，我可以看到以下内容
-
内部版本1
- 来自e0faff8f（主要发行人为2019-12-02提交版本2.97）
- 到db225f14（在PR完成2019-11-21之前从功能分支）
-
第2版
- 来自aeaf3dc5（已发布发行版2019-12-03 Cherry）
- 发送至e0faff8f（拉取请求分支2019-12-03）
-
第3版
- 来自f2ce6d3d（发行分支2019-12-06）
- 至f3db8c7b（2019-12-02）
我什至还不清楚构建管道如何知道其中包含的git commit范围，这也许是理解链接的关键。当然，它是从生成运行的提交中获取“发件人”部分的，但是它如何知道应该去哪个提交？
在上面的示例中，即使为该构建项目链接到构建1或构建3的范围似乎都没有与项目（cb9120d0）相关的提交？
这一切都很令人困惑和模糊。
有人能正确/可靠地使用此功能吗？
我还想知道我们是否需要为每个分支创建特定的管道，以便每个分支是独立的，但是我不确定即使您创建了一个全新的管道并将其指向主分支，它也不包含每个分支一次提交（和工作项）。同样，它怎么知道从哪里开始？