为发布分支计时

Question

团队的一部分正在致力于下一个版本/冲刺，其余人员则致力于在发布到生产之前测试和修复上一个冲刺的错误。

致力于下一个版本的部分现在就想要分支，另一部分则希望尽可能晚地分支，因为一旦我们分支，他们就必须开始合并修复。

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

有什么意见或建议吗？ 谢谢

注意：

这在过去是一个更严重的问题，因为我们使用 tortoisesvn 1.6 和 1.4 存储库，这阻止了 GUI 执行分支/合并操作。 因此，我通过升级存储库消除了这个障碍。 至少现在团队成员应该很容易合并。

Answer 1

需要考虑的另一点是：

考虑将渐进式代码（最活跃使用的代码假定为面向新版本的代码）保留在 TRUNK 上。 从 HEAD（或以前的基线版本，如果您已标记它）中分支出来，以供错误修复团队使用。 如果他们愿意，他们可以继续修复错误并定期从主干合并以获取最新开发的更新。

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

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

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

HTH。

Answer 2

在 SVN 中，分支不一定是一个痛苦的过程 - 特别是使用最新版本的 TortoiseSVN 和 SVN 客户端。 它需要一些 VCS 和存储库的知识，但这对于任何软件开发人员来说都是必需的。

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

尽早分支还可以让您的错误修复更多地暴露出来，因为冲刺开发人员可以在新功能的单元和功能测试期间执行它们。 更多曝光=更好的无错误修复。

Answer 3

我强烈推荐使用 Git/Mercurial 来解决此类问题。 :)

但既然我知道这不是一个选择，我只想说，对于这些类型的问题确实没有 100% 好的答案。 一般来说，我倾向于在流程的最后阶段才进行分支，因为分支和与 CVS/SVN 的合并往往是重量级流程。 您推迟分支流程的时间越长，在很多方面对您来说就越好。 但正如开发新功能的团队所知，这种情况只能持续这么长时间……在某些时候，推迟新功能的成本会超过推迟合并的好处。

在我现在的情况下，这通常会导致在新版本发布前 1-2 周（有时甚至更短）出现分支。 但确切的时间总是根据驱动版本的特定压力以及即将发布的新功能而变化。

Answer 4

一旦您进入某个版本的功能冻结状态，您就必须进行分支，以便开发下一个版本的团队不会继续破坏您试图放置的版本。 尝试进一步延迟分支只会导致更多问题。

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

这与使用 DVCS 获得的工作流程类似，不同之处在于所有分支都清晰可见，而不是分布在开发人员的计算机上。

Answer 5

尽可能晚地分支。