在TFS分支指南2010 v1（here）中，ALM Rangers目前为您提供了4个分支计划（方案）。
但是在一个相关的项目，TFS指南，也来自ALM游骑兵（here），他们提供了一个场景“没有分支”。这是一个很好的起点，因为例如2个分支（dev和main）会降低速度，并且由于所有FI（前向集成）和RI（反向集成）处理而引入更多复杂性。
我认为ALM Rangers不同步这两个项目，因为分支指南2010 v1不再提供“无分支”计划....
对于我们公司，我们希望定义一个指导，说明在开始时使用简单模型，但有能力在需要时增长。所以实际上，我们只想开始在Main分支上直接使用和开发，当QA真的成为问题时，我们可以开始进入开发分支并沿着分支进行合并。
这是一个很好的做法吗？
答案 0 :(得分：3)
如何进行分支是您在源代码配置管理方面可以做出的最重要决策之一。它需要与您的组织，流程和团队相匹配。
你在很大程度上决定早期将会永远使用的东西，所以不要轻易做出决定。
我的个人建议（仅因为它适用于我们）是使用MAIN和DEV分支方法。这提供了在合并到MAIN分支之前执行一定程度的质量保证（例如，试验构建）的能力。 DEV分支成为您的主要集成分支，因此前向集成不是一个负担（因为每个人都在DEV分支工作）。
为了给你一些参考，我们花了3到6个月的时间讨论我们的分支策略，通过用例运行并尝试在其中挖洞，然后再决定使用哪一个。