我是使用 git 和 Azure DevOps 来管理我们工作的开发团队的一员。
我们在 Azure DevOps 中的工作项通过添加链接的方式显示更新，远远超出了我们将相关代码合并到我们的发布分支的点。我不知道我们的工作项或过渡配置是否存在问题，或者我们的开发过程是否存在问题，或者两者都有。
症状：
- 当我们将工作中的开发分支的代码合并到发布分支（两个长期存在的 git 分支都使用策略管理）时，我们会看到数十或数百个过去的工作项可以追溯到几个月前，并且很久以前就已完成，与合并 PR 相关联。也许这与这个问题有关？
- 在大多数已关闭的工作项目上，我们看到以添加链接的形式持续更新，这些更新针对不同类型的看似不相关的活动或某个长期存在的分支上的活动。
最终结果是僵尸工作项使长期分支之间的合并变得混乱。
我们想要实现的是合并到我们的发布分支，其中 PR 仅包含与该发布中的新代码相关的工作项。并且一旦部署了一个工作，相关的工作项就不再更新。
我们的代码流程如下所示：
- 开发人员在本地分支工作并提交 PR 以将他们的工作提交到我们的共享开发分支。
- 在代码审查和批准后，PR 被压缩到共享开发分支中。
- 在代码冻结时，我们使用合并（非快进）策略将共享开发分支合并到发布分支。
- QA 团队对发布候选者进行认证。错误被修复并通过 squash 提交直接合并到发布分支中。
- 部署后，对发布分支的更改将合并回使用合并（非快进）策略的共享开发。
我们可以进行任何更改来清理我们的工作项管理吗？
更新：
我们将工作项关联到拉取请求（由分支策略强制执行），从不明确关联到分支。当 PR 被批准时，工作项与提交和 PR 相关联：
重申一下这个问题，除非我们以某种方式手动干预，否则 Azure Devops 现在会在每次我们在长期存在的分支之间合并代码时创建一个新的提交链接和 PR 链接。
在下面的示例中，展示了提交链接（PR 链接也看起来像这样），用户故事在 7 月 9 日被批准并提交给开发分支，并在当天晚些时候完成了合并到发布。理想情况下，这将是最后一个链接，但相反，我们会看到为两个长期存在的分支之间的每个后续合并创建一个链接。
如果您只关注 7 月 16 日从发布到开发的合并，这就是为什么我怀疑确定差异的方式有问题。这个工作项已经在开发中，所以两个分支不同的唯一方式就是查看历史记录。如果我理解正确的话，这就是 Azure Devops 的工作方式，但这也是许多组织的痛苦之源。
