需要基于干线的开发建议

Question

在进行功能分支几年后，我在寻找分支策略方面的良好资源，并在很多分支机构和合并噩梦中挣扎。功能分支确实为我们提供了一个很好的隔离，以非常精细的方式管理版本，以便发布哪些功能。然而，他们提出的问题（许多分支，合并冲突）不仅仅是他们给予的好处。

我们在后端使用Oracle数据库（包含5000个对象）。我们还有多个团队在同一产品的不同领域开展工作。我们正在使用带有TFS的Visual Studio（没有DVCS）。

我们创建的分支越多，我们需要更多的数据库实例，以便在这些分支（每个分支 - 一个数据库实例）中的功能测试中进行适当的隔离，这是另一组问题。

我们正在采用scrum并正在寻找适合我们发布周期（每年4次）和CI构建的分支模型。我们计划为每个版本执行5次常规sprint和1次强化sprint。

从功能分支模型中，我们将分支模型重新设计为如下所示的非常简单的分支 -

开发部门正在作为我们的＆＃34; Trunk＆＃34; （对于基于Trunk的开发）和所有开发人员（所有团队）都承诺到这个分支（每季度发布），测试人员正在这个分支中进行测试，CI服务器（Jenkins）每天都在构建这个分支。为了安全，我们只需要一个干净的MAIN作为最后发布的单一真相来源＆＃34;经常出于几个原因使用它们。

维护分支是我们的错误修复分支（修补程序），并在一年中多次发布（无论季度发布）。我们不希望直接在主分支上工作，因为我们希望有一个＆＃34; clean＆＃34;主枝。我们不希望代码在没有＆＃34;手册＆＃34; /功能测试完成。完成错误修复发布后，代码将从维护 - ＆gt;合并。主要 - ＆gt;开发将错误修复集成到开发中。

我们通常不需要＆＃34;发布分支＆＃34;正如TBD中所建议的那样，因为我们将继续在维护分支中执行错误修复，从维护版本中释放，然后将更改合并到Main（然后是开发）。我们只保留＆＃34;最后发布＆＃34;如果需要先前的Release修复，我们将从Main的Labels创建一个旧版本分支。

我们是否已将基于干线的开发修改为将来会出现问题的程度？你有什么建议吗？

参见：

http://paulhammant.com/2013/12/04/what_is_your_branching_model

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723

Answer 1

只有遇到错误时，才应该从已发布的标记中创建一个maintence分支。实际上，这是一个发布分支，它应该以发布命名。说rel_1.1。当您推出版本1.2并且很明显您不会回滚时，请删除rel_1.1。