TFS - 这种情况下最好的分支策略是什么？答案

【问题标题】：TFS - What is the best branching strategy for this scenario?TFS - 这种情况下最好的分支策略是什么？
【发布时间】：2013-12-18 20:01:59
【问题描述】：

我的目标是有这样的结构：

Project X
-- Main
-- QA
-- Dev
  -- Feature X

理想情况下，在开发新功能时，我想从“Main”主干分支并创建一个新的“Dev/Feature X”分支。一旦我准备好测试功能，我想使用合并工具将“功能 X”移动到“QA”。然后在完成并测试后从“QA”分支开始。一旦这是真的，我想从“QA”合并到“Main”。

这可能吗？我想在不进行毫无根据的合并的情况下做到这一点。我不确定如何构建分支以实现此解决方案。

【问题讨论】：

【解决方案1】：

是的，这是可能的。

您将Main 分支到QA，然后将QA 分支到Feature X、Feature Y 等。

然后，在Feature 分支中开发代码，当功能完成后，将功能分支中的代码合并到QA 分支。让开发人员定期从 QA 反向集成到他们的功能分支也很重要，以确保所有最新更改都存在并在他们的开发分支中工作。

当发布完成并在 QA 分支中进行测试后，将其合并回 Main，然后（如果需要）将 Main 分支到 Release 分支。

在这种情况下，Main 应该始终代表经过严格审查的、可交付的代码——您刚刚发布的代码，或者您即将发布的代码.如果Main 不经过（至少）QA 分支，任何人都不应该修改它。

基本上，您缺少的部分是您的代码应该始终通过QA 分支。我通常将其称为“集成”分支而不是“QA”，但目的是一样的。

ALM Rangers 有一个 awesome branching/merging guide——我强烈推荐阅读它！

【讨论】：

当然。我明白了，我知道这会奏效。我也认为我们会走这条路，但我问的是是否可以做所有这些，除了 Dev 的分支从 Main 到 Feature X（不是 QA 到 Feature X）。我猜这是行不通的，因为 QA 不会是 Feature 的“父级”，所以 TFS 不会让他们以后将 Feature X 合并到 QA 中。对吗？
没错——这将是毫无根据的合并。推荐的方法是我谈到的。