我们正在使用TFS 2010以及Branching Guide on codeplex中概述的基本分支计划 用于内部Web应用程序。我们只有3个基本分支= Dev，Main（QA / Testing）和Release（Production）。
由于该应用程序是内部Web应用程序，因此我们仅支持单个生产版本。
我们基本上在本地开发，一旦完成任务（错误修复或增强），我们就会将其提交给Dev。当我们开始工作以取消其他开发人员检查的任何内容时，我们通常每天都会从Dev获取最新信息。经过一段时间（通常是一周或两周）之后，我们将决定是否有足够的更改来证明更新QA站点并从Dev到Main进行合并，然后将合并的Main分支部署到QA服务器进行测试。
然后，QA将开始测试该站点，在他们满意之后，我们将执行从Main到Release的Merge All并将合并的Release分支部署到我们的生产服务器。有时我们甚至会在实际合并所有内容之前完成多个Dev-to-Main合并。无论如何，我们现在已经使用这个策略几个月了，直到最近，一切都看起来很棒。如果我们遇到生产中的一些关键问题，然后将其向后合并，我们就可以修复Release。一切都很好看。
然后我们遇到了一些我们不知道如何处理的事情。我们得到了指令，只需合并一个代码修复从Main到Release（不合并Main中的其他所有内容）。现在因为我们不知道这件事即将到来，当原始变更集从Dev合并到Main时，它与其他几个变更集合并在一起。因此，当我从Main合并到Release时，我唯一的选择就是整个合并的changset。我无法“深入”到合并的变更集中，只从Dev中选择一个我真正想要的原始变更集。
我手动应用这个更改就像Release中的修补程序一样，只是为了让它出来。但现在我正在努力了解你如何防止这样的情况。
我已经阅读了几篇关于合并策略的文章，所有内容似乎都建议你在合并时不要采摘樱桃 - 简单地合并所有可用的东西......这很有意义......但是如果你总是合并多个变更集（和它们成为目标分支中的一个变更集，那么如果需要，您如何才能将原始变更集中的一个合并到生产中？
例如，如果将Dev（C1，C2，C3）合并到Main（变为C4） - 那么如何仅将C4从'内'C4合并到Release？
这让我觉得我们最好将每一个变更集从Dev合并到Main，而不是一次完成几个。至少那时，如果需要，我们可以很容易地从主要版本升级到释放版本。
任何建议/生活课程/等。关于处理这个特定场景的分支/合并的问题将不胜感激。
答案 0 :(得分：1)
在您的方案中，您可以完成以下操作：
在此之后，您在Main中具有与之前相同的代码库，现在您可以将C6（仅具有C1的更改）从Main合并到Release。
但是，为了防止将来发生此类问题，您应该考虑将每个变更集从dev合并到main。
答案 1 :(得分：1)
我不建议将每个变更集从dev合并到main;这将是一个坏主意，还有更多的风险！
但是如果你总是合并多个变更集（它们就变成了一个变更集） 目标分支中的变更集），那么你如何潜在 如果是，则仅合并原始变更集中的一个 需要出现吗？
你没有也不应该让需要出现。
这可能不是您正在寻找的简单答案，但确实没有简单的答案。合并每一个变更集都会产生大量的努力来为不应该发生的事情做准备。事实上，合并个别变更集的过程引入了更多的复杂性，当你无法弄清楚为什么你的软件不起作用时，最终会让你陷入困境......“大坝，我错过了变更集43满分50分......“
如果是错误的结果：
在您的方案中，如果您手动将“修复”重新应用于Release的“修补程序”分支或直接重新应用于Release行，可能会更好。
这只是让错误进入生产的成本，我会花一点时间弄清楚为什么这个问题通过QA以及如何在将来阻止它。
如果是增强效果的结果：
您的财务（CFO）人员是否授权降低生产质量，这是运送未经测试的代码的直接结果？我希望他们能够有效地拥有该软件被列为组织资产的余额报表！
将一个功能（仅使用其他功能构建和测试）发布到生产环节是不可行的，而无需再次完成整个回归周期。
<强>结论
我不建议将每个更改集或功能从dev合并到main;这对于适当的人来说应该是高亮的额外风险是一个坏主意！