版本升级与版本分支的优缺点

Question

在我目前的项目中，我必须决定在分支时使用哪种技术。我有两个选择（我们假设我们已经决定在主干中开发）：

版本分支

每当在测试机器上放置新版本时创建一个分支，并将其标记为“release0.1”。错误在这个分支中被修复（当然然后合并到主干），当这个版本最终生效时，它被标记为“release0.1.1”。这导致每个主要版本都有一个分支，每个次要版本都有一个标记。如果必须在实时版本中修复错误，则将其修复为适当的分支，然后合并到主干。

版本推广

只有三个分支“trunk”（用于开发），“test”和“live”。当一个版本放在测试机器上时，主干被合并（提升）到“测试”分支，在该分支中修复了错误，当版本发布时，“test”分支被合并到“实时”分支中。如果我们在“实时”分支中发现了一个错误，它会在那里修复，然后合并到主干。

这两种哲学的利弊是什么？你有什么经历？还有其他 - 可能更好 - 的方法吗？

Answer 1

这取决于您的维护政策。

如果您选择维护的数量超过最新版本（例如XP与Vista并行），版本分支是更好的选择。

Answer 2

根据我的经验，版本促销在合并来自不同分支的更改并尝试记住在哪个分支上修复了什么等方面的开销要小得多，所以无论何时我都喜欢以这种方式工作。不幸的是，如果你使用版本升级，通常不可能对发布的版本做一些小的快速修复（因为在“测试”分支中检查了大量的代码） - ＆gt;所以我们和版本分支。

总结一下，我认为（至少对我而言）通常最好的方法是在两者之间做一些事情 - 在trunk（主分支）上进行所有开发，标记所有构建/发布，并仅创建一个版本分支如果需要（例如，生产中存在严重错误，并且主干中的更改无法释放）。

Answer 3

在我看来，这两个是独家注释。

如果您必须维护不同的RELEASED版本，则需要版本分支机制。但我认为在发布版本后始终准备分支点（取决于您的gestion版本系统）是最佳做法。

如果您必须发布测试版本，则需要“促销”机制。例如，如果您拥有与开发团队和/或开发速度快的大型团队不同的验证团队，那么这非常有用。在这些情况下，您需要一个特定的分支来稳定下一个“稳定”释放，而主干保持“不稳定”。