这不是我没有任何想法的问题，而是我想提出一个模型，看看它是否获得批准，或者任何人都可以看到它的问题或有更好的建议。他们说，为了避免未来的麻烦，最好谨慎选择分支模型。
所以我们有一个内部应用程序，只有一个版本（最新版本）发布给客户，基本上有两种开发活动：主要活动是为下一个版本工作，通常包括新功能和纠正修复它是有计划的，第二个是没有计划的，是关于维护的，包括生产中当前版本的修补程序。
经过长时间的研究，我们决定选择主主干，从中分出2个子分支：开发＆amp; 维护（或修补程序）。正如本指南中所介绍的那样，每当我们为下一个版本准备好功能时，每日开发都会发生在我们进行反向集成（RI）的开发分支中。在发布之前，反向集成将停止，代码将在 Main 分支中稳定下来。从 Main 发布后，将会有从主要到开发和维护的正向集成（FI）。< / p>
任何修补程序都只会在维护中进行，并且根据修复程序（例如，如果我们想将其保留在代码库中），我们会在 Main 中执行RI从那里一个FI进入发展。
现在一切看起来都很好，至少在纸面上，所以我想听听别人对这个模型的看法。
例如，我们还考虑使用另一个分支发布，其中代码的稳定在发布到生产之前发生（而不是直接在 Main 中工作）和当然，我们将从这里发布到生产并进行RI到主要，然后进行FI到开发＆amp; 维护，但我们不确定这是否会带来任何好处或只会增加复杂性？
假设开发中的功能将无法为下一版本做好准备或不需要，这意味着我们将不得不对相关的变更集进行一些“挑选”想要的功能，但根据文档，这不是太好。有什么建议吗？
我再次知道这不是一个简单明了的问题，而是一个开放的问题，我仍然希望听到任何有类似经历的人。提前感谢您的关注。
答案 0 :(得分：4)
您是否阅读过TFS ALM Rangers分支指导文档？您提出的建议看起来非常像他们的“标准分支计划”，尽管他们鼓励同时拥有发布和“服务包”分支（很像上面的发布和维护分支）。
http://vsarbranchingguide.codeplex.com/
我已经在几个客户端实施了标准分支计划，并且没有遇到任何问题。如果您计划采用并发工作流（功能团队等），分支指南也有可靠的计划。
另一件需要考虑的事情可能是阶梯模型，您可以在每个版本中创建新的Dev分支，并将旧版本作为版本冻结。这样可以避免使用RI，因为您可以只修复旧版本，并在必要时修复新的Dev分支。我也在这个模型中工作，这很棒。