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