【发布时间】：2012-01-12 07:45:00
【问题描述】：
这不是我没有任何想法的问题，而是我想展示一个模型，看看它是否获得批准，或者任何人都可以看到它的问题或有更好的建议。他们说最好仔细选择分支模型以避免将来的麻烦。
所以我们有一个内部应用程序，只有一个版本（最新）发布给客户，基本上有两种开发活动：主要活动是为下一个版本工作，通常包括新功能和纠正修复它是计划中的，第二个是未计划的，是关于维护的，包括生产中当前版本的修补程序。
经过长期研究，我们决定使用 Main 主干，从中分出 2 个子分支：Development & Maintenance（或修补程序）。正如指南中介绍的那样，每天的开发将发生在 Development 分支中，每当我们为下一个版本准备好功能时，我们都会从该分支进行反向集成 (RI)。在发布之前，反向集成将停止，代码将稳定在 Main 分支中。从 Main 发布后，将有一个从 Main 到 Development 和 Maintenance 的前向集成 (FI)。
任何修补程序都只会在 Maintenance 中发生，并且取决于修补程序（例如，如果我们想将其保留在代码库中），我们将在 Main 中执行 RI 并从那里进入开发。
现在一切看起来都很好，至少在纸面上，所以我想听听其他人对这个模型的看法。
例如，我们还会考虑创建另一个分支 Release，其中代码的稳定发生在发布到生产之前（而不是直接在 Main 中工作）和当然，我们将从这里发布到生产环境并在 Main 中进行 RI，然后在 Development 和 Maintenance 中进行 FI，但我们不是确定这是否会带来任何好处或只会增加复杂性？
并假设 开发 中的某些功能不会为下一个版本准备好或不需要，这意味着我们将不得不对相关的变更集进行一些“樱桃采摘”到想要的功能，但根据文档，这不是太好。有什么建议吗？
我再次知道这不是一个简单直接的问题，而是一个开放的问题，我仍然希望听到任何有类似经历的人的意见。提前感谢您的关注。
【问题讨论】：
-
@KMoraz：我可以从另一篇文章中得出的结论是选择简单而明智，我喜欢这样。但是，我不确定只有 Dev & Main 对我们来说是否足够。我们需要在版本之间隔离修补程序的工作。感谢您的链接，我能得到的所有阅读内容都有帮助。