在做了几年的功能分支之后，我一直在寻找关于分支策略的良好资源，并且在很多分支机构和合并恶梦中苦苦挣扎 . 功能分支确实为我们提供了一个很好的隔离，以非常精细的方式管理版本，以便发布哪些功能 . 然而，他们提出的问题（许多分支，合并冲突）远远超过他们给予的好处 .
我们在后端使用Oracle数据库（带有5000个对象） . 我们还有多个团队在同一产品的不同领域开展工作 . 我们正在使用带有TFS的Visual Studio（没有DVCS） .
我们创建的分支越多，我们需要更多的数据库实例，以便在那些分支（每个分支 - 一个数据库实例）中的功能测试中进行适当的隔离，这是另一组问题 .
我们正在采用Scrum并正在寻找适合我们发布周期（每年4次）和CI构建的分支模型 . 我们计划为每个版本执行5次常规sprint和1次强化sprint .
从功能分支模型中，我们将分支模型重新设计为一个非常简单的分支，如下所示 -
开发分支正在作为我们的“主干”（用于基于主干的开发），并且所有开发人员（所有团队）都致力于此分支（每季度发布），测试人员正在此分支中进行测试，CI服务器（Jenkins）每天都在构建此分支 . 我们在任何时候都需要一个干净的MAIN作为“最后发布的单一真理来源”，我们经常出于几个原因使用它 .
维护分支是我们的错误修复分支（修补程序），并在一年中多次发布（无论季度发布） . 我们不希望直接在主分支上工作，因为想拥有一个“干净”的主分支 . 我们不希望在没有“手动”/功能测试的情况下让代码进入Main . 完成错误修复发布后，代码将从Maintenance - > Main - > Development合并，以将错误修复集成到Development中 .
我们通常不需要TBD中建议的“Release Branches”，因为我们将继续在维护分支中执行错误修复，从Maintenance中释放，然后将更改合并到Main（然后是Development） . 我们仅维护“最后发布”，如果需要先前的发布修复，我们将从主要的标签创建一个旧的发布分支 .
我们是否修改了基于干线的开发，以至于它将来会出现问题？你有什么建议？
参考：
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723
1 回答
只有在遇到错误时，才应该从发布的标记中创建一个维护分支 . 实际上这是一个发布分支，它应该以发布命名 . 说rel_1.1 . 当你推出版本1.2并且很明显你不会回滚时，删除rel_1.1 .