定时发布分支

Question

团队的一部分正在开发下一个版本/ sprint，其余部分正在进行测试，并在发布到生产之前修复上一个sprint。

处理下一个版本的部分现在想要分支，另一部分希望尽可能晚，因为他们必须在我们分支后立即开始合并修复。

我不喜欢让任何人等待提交，因为我们还没有分支。当他们不理解合并时，我也不喜欢浪费人们的时间。 （并且SVN不合并重命名）

有任何意见或建议吗？感谢

注意：

这在过去是一个更糟糕的问题，因为我们使用了1.4版本的tortoisesvn 1.6，这阻止了GUI进行分支/合并操作。所以我通过升级回购删除了这个障碍。现在至少应该让团队成员合并。

Answer 1

您需要考虑的另一点：

考虑在TRUNK上保持渐进式代码（最常用的代码被认为是新版本的最新版本）。为了使用错误修正团队，从HEAD（或先前的基线版本，如果你已标记它）分支出来。如果他们愿意，他们可以定期修复错误并从主干中合并以获取最新开发的更新。

另一方面，新的发布工作在TRUNK上进行，TRUNK可以指定用于始终代表“当前”或“生产”环境中的内容。如果您想将针对先前版本所做的修复恢复到curent版本中，您可以从错误修复分支合并回TRUNK。

此模型也可以在下一个发布标记之后迭代。

根据我的经验，这有助于最大限度地减少合并，因为错误修复的数量会减少，因此这意味着较少的文件会在需要时合并回TRUNK。在大多数（我说最不是全部:-)）情况下，错误修正的开发人员数量会减少，所以这意味着需要合并的文件数量会减少。

HTH。

Answer 2

我强烈推荐Git / Mercurial用于解决这些问题。 ：）

但是既然我知道这不是一个选择，我只会说这些类型的问题确实没有100％的答案。一般来说，我倾向于不在分支过程中尽可能不分支，因为与CVS / SVN的分支和合并往往是重量级过程。你可以延迟分支过程的时间越长，你在很多方面就越好。但是，正在研究新功能的团队知道，这只能持续这么久......在某些时候，延迟新功能的成本超过推迟合并的好处。

我现在所处的位置，通常会在发布新版本之前产生1-2周（有时甚至更少）的分支。但确切的时间总是根据推动发布的具体压力和即将发布的新功能而变化。

Answer 3

分支在SVN中不一定是一个痛苦的过程 - 尤其是最新版本的TortoiseSVN和SVN客户端。它需要一些VCS和repo的知识，但任何软件开发人员都应该这样做。

需要考虑的是在每个开发阶段可能会出现多少新代码和多少修改。通常，冲刺/释放阶段产生比错误修复阶段更大的变化集。这意味着立即分支并合并较少数量的错误修复更为明智。在大多数情况下，等待分支会导致更加混乱。

早期分支也会让您的错误修复更多曝光，因为短跑开发人员可以在新功能的单元和功能测试期间执行这些操作。更多暴露=更好的无错误修复。

Answer 4

一旦你进入功能冻结版本，你必须做分支，以便在下一个版本上工作的团队不会继续打破你试图上床的那个。试图进一步推迟分支，这只会导致更多问题。

如果您使用功能分支，那么这将变得更容易。所有修复都发生在trunk中，你保留一个RC分支，你将从中释放，你可以在进行测试发布之前从trunk到它进行批量合并。功能分支从主干合并，只有在功能准备好后才会合并回主干。虽然这听起来会导致更多的合并，但它使所有合并变得非常简单。

这类似于您使用DVCS所获得的工作流程，除了所有分支都在视线范围内，而不是在开发人员的机器周围传播。

Answer 5

尽可能晚地分支。