tfs - 将多个变更集合并为一个后如何挑选

Question

我们将 TFS 2010 与 Branching Guide on codeplex 中概述的基本分支计划一起使用用于内部 Web 应用程序。我们只有 3 个基本分支 = Dev、Main(QA/测试)和 Release(生产)。

因为该应用程序是一个内部网络应用程序，所以我们只支持单一的生产版本。

我们基本上是在本地开发，一旦我们完成了一项任务(错误修复或增强)，我们就会将其提交给 Dev。当我们开始工作时，我们通常还会每天从开发人员那里获取最新信息，以提取其他开发人员 checkin 的任何内容。一段时间后(通常是一两周)，我们将决定我们有足够的更改来证明更新 QA 站点是合理的，并执行从 Dev 到 Main 的所有合并，然后将合并的 Main 分支部署到 QA 服务器以进行测试。

然后 QA 将开始测试站点，在他们满意之后，我们将执行从 Main 到 Release 的所有合并，并将合并的 Release 分支部署到我们的生产服务器。有时，我们甚至会在真正将所有内容合并到 Release 之前进行多次 Dev-to-Main 合并。

无论如何，我们已经使用这个策略几个月了，直到最近，一切看起来都很棒。如果我们在生产中遇到一些关键问题，然后将其向后合并，我们就能够修补 Release。一切看起来都很好。

然后我们遇到了一些我们不知道如何处理的事情。我们得到的指令是仅合并从 Main 到 Release 的单个代码修复(不合并 Main 中的所有其他内容)。现在因为我们不知道这会发生，所以当原始变更集从 Dev 合并到 Main 时，它与其他几个变更集一起合并。因此，当我从 Main 合并到 Release 时，我唯一的选择是整个合并的变更集。我无法“向下钻取”合并的变更集并只从 Dev 中选择一个我真正想要的原始变更集。

我最终手动应用更改，就像 Release 中的修补程序一样，只是为了让它在那里。但现在我正试图了解您如何防止出现这种情况。

我读过几篇关于合并策略的文章，所有内容似乎都建议在合并时不要挑选变更集 - 简单地合并所有可用的东西......这是有道理的......但如果你总是合并多个变更集(并且它们成为目标分支中的一个变更集)，那么如果需要的话，您如何可能仅将原始变更集之一合并到生产环境中？

例如，如果将 Dev(C1、C2、C3)合并到 Main(成为 C4)——那么如何从 C4“内部”直至 Release 仅合并 C1？

这让我觉得我们最好将每个单独的变更集从 Dev 单独合并到 Main，而不是一次合并多个。至少，如果需要的话，我们可以很容易地从 Main 升级到 Release。

任何建议/生活类(class)/等。将不胜感激处理此特定场景的分支/合并。

Answer 1

在您的场景中，您可以执行以下操作:

• Rollback Main 中的 C4(变为 C5，因为回滚本身就是变更集，它应用反向变更)
• 再次从 Dev 合并到 Main，但这次只选择 C1(在 Main 中变成 C6)。
• 现在再次回滚变更集 C5 和 C6，这样您就可以像以前一样在 Main 中进行所有更改。 (在 Main 中成为 C7)。

在此之后，您在 Main 中拥有与之前相同的代码库，并且您现在可以将 C6(仅包含 C1 的更改)从 Main 合并到 Release。

但是，为了防止将来出现此类问题，您真的应该考虑将每个单独的变更集从 dev 单独合并到 main。