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

Question

过去

我使用subversion作为scm开发了一个软件项目。到目前为止，开发始终发生在trunk中，因此当需要修复错误时会出现问题。现在，我们想重新考虑我们的分支策略，其要求是：我们希望能够同时处理多个未来版本。

任务

这意味着：假设，我们正在处理的当前版本是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是您可以查看的默认分支。
即：你不知道其他分支的命名约定，但你至少知道“main”分支被称为“trunk”，所以作为一个新的开发人员，你可能想要检查那个这就是为什么当前的开发最好在同一个分支中进行的。

分支1.0，1.1或2.0宁愿用于维护操作，一旦完成这些发布。

对于并行开发，我建议使用另一个命名约定，例如1.1_dev，2.0_dev，由trunk（代表当前1.0开发）制作。<登记/> 如果那些分支不是太长寿，并且它们与trunk之间没有太大差异（因为合并会变得越来越复杂），这可以起作用。