我们已经开始在 TFS 2010 中使用以下分支结构:
到目前为止，所有更改都在 Development 分支中执行，并且所有 checkin 都与一个 Task 工作项相关联。这些任务都是 Bug 或 Product Backlog Item 工作项的子项。每个 CI 构建都是针对特定的变更集触发的，并且变更集与一个任务相关联，因此我们可以手动确定刚刚构建了哪个 Bug 或 PBI。
在代码构建、部署到我们的集成环境并由开发人员测试后的一段时间，它被合并到主分支。显然，可以同时将多个变更集合并到 Main。如果我们在此之前不手动触发 nightly，则 nightly build 将构建此代码。 QA 稍后会将这些“主要”构建之一部署到 QA 环境。
自从上次部署 QA 以来，可能已经对 Main 分支进行了多次构建。这些构建与“合并”变更集相关联，而不是与与任务关联的原始变更集相关联。
如何确定给定“主要”构建已解决的任务集，该构建是与与任务工作项关联的分支不同的分支的构建？
一旦我们开始准备发布，我们很可能需要在发布分支中进行更改，这将使事情变得更加复杂，因为我们将从发布合并回主，并且发布变更集将与任务相关联。然后这些将合并到开发中，让生活变得更加有趣!
附言问题“How to determine the work items associated with a source branch in TFS 2010?”接近于问同样的问题，但不完全是。
最佳答案
看看 Jacob Ehn 的博客文章 Automatically Merging Work Items in TFS 2010 .他写了一个插件，可以从codeplex下载.它将自动关联与合并的变更集关联的工作项。因此，当您合并到 Main 或 Release 时，工作项将与这些分支中的变更集相关联，并且工作项将包含在构建报告中，以便从这些分支构建。该插件非常易于部署。
关于tfs - 使用分支时如何确定特定 TFS 构建中修复的工作项？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7536323/