5

过去

我使用 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，其中还包括新功能，并且必须单独维护。

一个可能的解决方案

我提出了以下分支策略：

  • 后备箱将被遗弃
  • 对于每个新的计划发布，都会创建一个源自上一个发布分支的分支
  • 更改在版本时间线中“向上”传播

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

所描述的分支策略的可视化（请原谅糟糕的油漆质量）

问题

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

4

1 回答 1

2

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

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

对于并行开发，我会推荐另一种命名约定，例如1.1_dev, 2.0_dev，由trunk（代表当前1.0开发）制成。
如果这些分支的寿命不太长，并且它们不会偏离太多trunk（因为合并会变得越来越复杂），那么这可以工作。

于 2011-03-03T15:39:36.397 回答