合并特定工作项的更改答案

【问题标题】：Merge Changes for specific Work Item合并特定工作项的更改
【发布时间】：2010-09-29 04:37:46
【问题描述】：

在 TFS 2010 中，我们有一个开发分支，所有开发都针对一个产品完成。我想将其中一些更改合并到一个发布候选分支，以便可以对其进行测试和推出。因此，我想合并所有链接到我们要放入候选发布的特定工作项的变更集。

我可以跟踪特定工作项的所有变更集，但我无法轻松地将它们合并到 RC 分支中。我既不能在层次跟踪视图中拖动多个变更集，也不能在合并向导中预先选择变更集。默认情况下，它总是希望将所有变更集 UP 合并到拖动的变更集，这绝对不是我想要的。由于可能有几十个变更集，我不想手动选择它们。

有没有办法以“正确”的方式做到这一点？

【问题讨论】：

标签： tfs branch

【解决方案1】：

您所说的是“樱桃采摘”合并。总体而言，cherry-pick 合并不是最佳实践，因此如果您认为这种情况会发生很多，您可能应该重新审视您的分支策略（例如，功能分支与发布分支）。然后你可以简单地合并整个分支而不是做樱桃挑选。

你会发现 TFS 不能很好地支持这种类型的合并。当您合并变更集时，它将合并所有文件，包括该变更集。您也许能够在特定变更集中标记文件并根据标签进行合并，但我怀疑这是否可行。

我们的组织中存在需要支持此类功能的情况。最终，我们编写了一个实用程序，允许我们从多个变更集中挑选文件并将它们合并到一个分支。执行此操作的代码相对简单。

【讨论】：

除了 Robaticus，修改你的发布策略。我建议将发布中的所有功能都部署到候选发布，因此您还可以对您的应用程序执行集成测试。
谢谢大家，我们终于得出了相同的结论。现在我们必须为我们当前的分支策略找到一个替代方案。但是我怕以后有几十个特性分支。一种方法是在分支合并到主开发后将其删除。此外，我们可以为那些无法包含在下一个版本中但应该已经启动的功能创建功能分支。
我们确实花了几个月的时间来决定一个分支策略。这是实施 TFS 最困难的部分。
@JensMig 您是否有能力在任何特定时刻为单个产品执行多个功能？如果是这样，请确保您在团队之间进行良好的沟通以阻止合并冲突。还要尝试对产品功能进行分区，以便最大限度地减少冲突。如果您没有这种能力（1 个 5 到 10 名成员的团队），我强烈建议您找出最重要的功能并一直工作直到完成 - 可交付。最好有 1 个功能准备好发布，而不是 5 个几乎准备好。