并行开发分支策略

Question

我面临着在未知的时间段内需要维护同一产品的两个版本的挑战。我想我已经提出了一个可行的解决方案，但我想将它从社区中反弹出来进行“健全检查”。当前请求新功能时，从主干切断分支，在该分支中完成开发，并将该分支合并回主干。这是我工作过的大多数地方的典型策略。

最近，一个新的分支机构被削减进行重大功能检修，这将导致与主干不兼容的变化。我们的所有用户最终将被强制使用这个新版本，但是，在一段时间内，两个版本都将存在。在我深入研究之前，这里是我目前的分支计划

的图表

版本：Current是当前发布的。随着版本：New的开发，将继续为版本发布错误修复：当前（很可能）将需要合并到版本中：新版显然版本的任何新功能/错误修复：新版本只需要合并进入版本：新的。一旦Version：Current不再出现在该字段中，Version：New将成为单一的主干。虽然我认为这是可行的，但我认为它很快就会成为管理层的噩梦。我的问题是：在我的情况下是否有一个“更好”的分支策略可以遵循，或者这就是它？

Answer 1

您应该选择最适合您的团队及其工作方式的分支策略。但你所描述的是一种非常常见的做事方式。我想补充一点，您可能希望更频繁地合并当前版本的错误修复，而不是仅在当前版本未使用之后。如果那段时间很长，分支可能会相互远离，导致头痛。

Here是关于常见分支模式的好文章