在进行了几年的功能分支并在许多分支和合并噩梦中苦苦挣扎之后，我正在寻找有关分支策略的良好资源。功能分支确实为我们提供了一个很好的隔离，以一种非常精细的方式管理发布，以确定哪些功能应该发布。然而，他们带来的问题（许多分支、合并冲突）远远超过了他们带来的好处。
我们在后端使用 Oracle 数据库（有 5000 个对象）。我们还有多个团队致力于同一产品的不同领域。我们正在使用带有 TFS（无 DVCS）的 Visual Studio。
我们创建的分支越多，我们需要的数据库实例就越多，以便在这些分支（每个分支 - 一个数据库实例）的功能测试中提供适当的隔离，这是另一组问题。
我们正在采用 Scrum 并正在寻找适合我们的发布周期（一年 4 次）和 CI 构建的分支模型。我们计划为每个版本进行 5 次常规冲刺和 1 次强化冲刺。
从一个特征分支模型，我们将我们的分支模型重新设计为一个非常简单的分支，如下所示 -
开发分支作为我们的“主干”（基于主干的开发）工作，所有开发人员（所有团队）都致力于这个分支（季度发布），测试人员正在这个分支中进行测试，CI 服务器（Jenkins）每天都在构建这个分支. 为了安全起见，我们随时都需要一个干净的 MAIN 作为“最后一次发布的单一事实来源”，我们经常使用它有几个原因。
维护分支是我们的 bug 修复分支（hotfix），一年内发布多次（不考虑季度发布）。我们不希望直接在主分支上工作，因为希望有一个“干净的”主分支。我们不希望在没有完成“手动”/功能测试的情况下让代码进入 Main。一旦错误修复发布完成，代码将从维护 -> 主 -> 开发合并，以将错误修复集成到开发中。
我们通常不需要 TBD 中建议的“发布分支”，因为我们将不断地在维护分支中进行错误修复，从维护中发布，然后将更改合并到 Main（然后是 Development）。我们只维护“最后一个版本”，如果需要以前的版本修复，我们会从 Main 中的标签创建一个旧版本分支。
我们是否对基于主干的开发进行了修改，以至于将来会出现问题？你有什么建议？
参考：
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723