在一次开发多个未来版本时,什么是良好的分支策略？

Question

过去

我使用subversion作为scm开发了一个软件项目.到目前为止,开发总是发生在trunk,所以当需要修复bug修复时会出现问题.现在,我们想重新考虑我们的分支策略,其要求是:我们希望能够同时处理多个未来版本.

任务

这意味着:假设,我们正在处理的当前版本是1.0.下一个计划版本是2.0,之后的版本是3.0.现在我们已经发布了1.0版本

• 维护1.0版
• 开发2.0的功能
• 同时开发3.0的功能

当然,在其他两个版本中也需要在1.0中应用的修补程序.此外,2.0的功能也必须在3.0.此外,可能会计划一个次要版本,例如1.1,其中还包括新功能,并且必须单独维护.

可能的解决方案

我提出了以下分支策略:

• 行李箱将被废弃
• 对于每个新的计划发布,都会创建一个源自最后一个发布分支的分支
• 更改在版本时间轴中"向上"传播

让我再详细说明一下:在给定的示例中,我们将从trunk分支1.0版.此外,我们将从版本1.0分支2.0版,从2.0版分支3.0版.当在1.0中进行更改时,它将合并到2.0,然后合并到3.0.

这个问题

这是一种有效的方法吗？它会在技术上有效吗？是否存在组织缺陷？有最佳做法吗？(所有互联网都会提出:"在主干中开发,在发布分支中维护").放弃后备箱对我来说特别奇怪 - 这是错的吗？

Answer 1

“在其中开发”的想法trunk来自于这样的事实trunk：您可以想要签出的默认分支。
即：您不知道其他分支的命名约定，但您至少知道“主”分支称为“ trunk”，因此作为新开发人员，您可能会忍不住检查该分支，这就是为什么当前的开发最好在同一分支中进行。

一旦这些版本完成，分支或宁愿1.0用于维护操作。1.12.0

对于并行开发，我建议使用另一种命名约定，例如1.1_dev, ，由(代表当前的开发)2.0_dev组成。 如果这些分支的寿命不是太长，并且它们没有太大的分歧（因为合并会变得越来越复杂），那么这种方法就可以工作。trunk1.0
trunk