svn - 一次开发多个 future 版本时，什么是好的分支策略？

Question

过去

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

任务

这意味着:假设我们正在开发的当前版本是 1.0。下一个计划的版本是2.0，之后的版本是3.0。现在我们已经发布了 1.0 我们想要

维护 1.0 版

为 2.0 开发功能

同时为3.0开发功能

当然，其他两个版本也需要1.0中已经应用的修复。此外，2.0 中的功能也必须在 3.0 中。此外，可能会计划发布一个次要版本，例如 1.1，其中还包含新功能，并且必须单独维护。

一个可能的解决方案

我提出了以下分支策略:

后备箱将被废弃

对于每个新的计划发布，都会创建一个分支，该分支源自最后一个发布分支

更改在版本时间线中“向上”传播

让我详细说明一下:在给定的示例中，我们将从主干分支版本 1.0。此外，我们将从 1.0 版和 3.0 版从 2.0 版分支到 2.0 版。在 1.0 中进行更改时，它将合并到 2.0 中，随后合并到 3.0 中。



问题

这是一种有效的方法吗？它会在技术上起作用吗？是否存在组织缺陷？有最佳实践吗？ (所有互联网都会提出:“在主干中开发，在发布分支中维护”)。放弃后备箱对我来说尤其奇怪——这是错误的吗？

Answer 1

“在trunk中发展”的想法来自于trunk是您想要结帐的默认分支。
即:你不知道其他分支的命名约定，但你至少知道“主”分支被称为“trunk”，所以作为一个新的开发人员，你可能很想 checkout 那个，这就是为什么当前的开发最好在同一分支中进行的原因。

分行1.0 , 1.1或 2.0更愿意用于维护操作，一旦这些版本完成。

对于并行开发，我会推荐另一种命名约定，例如 1.1_dev , 2.0_dev ，由 trunk 制成(这将代表当前的 1.0 开发)。
如果这些分支的生命周期不是太长，并且它们与 trunk 的分歧不大，那么这可以工作。 (因为合并会变得越来越复杂)。