我们将 TFS 2010 与 内部 Web 应用程序的codeplex 分支指南中概述的基本分支计划一起使用。我们只有 3 个基本分支 = 开发、主要（QA/测试）和发布（生产）。
由于该应用程序是一个内部 Web 应用程序，因此我们仅支持单个生产版本。
我们基本上是在本地开发，一旦我们完成了一项任务（错误修复或增强），我们就会将其提交给 Dev。当我们开始工作以拉下其他开发人员签入的任何内容时，我们通常还会每天从 Dev 获取最新信息。一段时间后（通常是一两周），我们将确定我们有足够的更改来证明更新 QA 站点的合理性，并执行从 Dev 到 Main 的 Merge All，然后将合并的 Main 分支部署到 QA 服务器进行测试。
然后 QA 将开始测试站点，在他们满意后，我们将执行从 Main 到 Release 的 Merge All 并将合并的 Release 分支部署到我们的生产服务器。有时我们甚至会在将所有内容合并到 Release 之前进行多次 Dev-to-Main 合并。
无论如何，我们已经使用这个策略几个月了，直到最近一切看起来都很棒。如果我们在生产中遇到一些关键问题，我们可以对 Release 进行修补，然后将其向后合并。一切看起来都很好。
然后我们遇到了一些我们不知道如何处理的事情。我们得到的指令是只合并从 Main 到 Release 的单个代码修复（而不合并 Main 中的所有其他内容）。现在，由于我们不知道这即将到来，所以当原始变更集从 Dev 合并到 Main 时，它与其他几个变更集一起合并。所以当我从 Main 合并到 Release 时，我唯一的选择是整个合并的 changset。我不能“深入”到合并的变更集中，只从 Dev 中挑选我真正想要的一个原始变更集。
我最终像 Release 中的修补程序一样手动应用更改，只是为了将其发布。但现在我试图了解您如何防止这种情况发生。
我已经阅读了几篇关于合并策略的文章，并且似乎所有内容都建议您在进行合并时不要挑选变更集 - 简单地合并所有可用的内容......这是有道理的..但是如果您总是合并多个变更集（并且它们成为一个目标分支中的变更集），那么如果需要，您如何可能仅将原始变更集之一合并到生产环境中？
例如，如果将 Dev (C1, C2, C3) 合并到 Main (成为 C4) - 那么如何仅将 C1 从“内部”C4 合并到 Release？
这让我认为我们最好将每个单独的变更集从 Dev 合并到 Main，而不是一次合并多个。至少，如果需要的话，我们可以很容易地从 Main 到 Release。
任何建议/生活课程/等。非常感谢处理此特定场景的分支/合并。