团队的一部分人正在处理下一个版本/sprint，其余的人在发布到生产之前进行测试和修复上一个 sprint 的错误。
下一个版本的工作部分现在想要分支，另一部分希望尽可能晚，因为一旦我们分支，他们就必须开始合并修复。
我不喜欢让任何人等待提交，因为我们还没有分支。我也不喜欢在人们不懂合并时浪费他们的时间。 （而且 SVN 不合并重命名）
有什么意见或建议吗？谢谢
注意：
这在过去是一个更严重的问题，因为我们使用带有 1.4 存储库的 tortoisesvn 1.6，这会阻止 GUI 执行分支/合并操作。所以我通过升级 repo 消除了这个障碍。至少现在团队成员应该很容易合并。
【问题讨论】：
标签： svn tortoisesvn release branch merge
另一点供您考虑：
考虑在 TRUNK 上保留渐进式代码（假定使用最频繁的代码是朝向新版本的代码）。从 HEAD（或以前的基线版本，如果您已标记它）分支出来，以供 bugfixer 团队使用。如果他们愿意，他们可以定期修复错误并从主干合并以获取最新开发的更新。
另一方面，新发布的工作在 TRUNK 上进行，并且可以指定 TRUNK 始终代表“当前”或“生产”环境中的内容。如果您想将以前版本的修复恢复到当前版本，您可以从 bugfix 分支合并回 TRUNK。
这个模型也可以在下一个发布标签之后迭代。
根据我的经验，这有助于最大限度地减少合并，因为错误修复的数量会更少，因此这意味着在需要时可以合并回 TRUNK 的文件更少。在大多数情况下（我说不是全部:-)）情况下，修复错误的开发人员数量会更少，所以这再次意味着需要合并的文件数量更少。
HTH。
【讨论】：
我强烈推荐使用 Git/Mercurial 来解决这类问题。 :)
但由于我知道这不是一个选择，我只想说对于这些类型的问题确实没有 100% 好的答案。一般来说，我倾向于在流程尽可能晚的时候才进行分支，因为与 CVS/SVN 的分支和合并往往是重量级的流程。您可以推迟分支流程的时间越长，您在许多方面的情况就越好。但正如开发新功能的团队所知道的那样，这种情况只能持续很长时间......在某些时候，延迟新功能的成本超过了延迟合并的好处。
在我现在的情况下，这通常会在新版本发布前 1-2 周（有时甚至更短）产生一个分支。但确切的时间总是会根据推动发布的具体压力以及即将发布的版本中的新功能而有所不同。
【讨论】：
在 SVN 中，分支不一定是一个痛苦的过程——尤其是使用最新版本的 TortoiseSVN 和 SVN 客户端。它需要一些关于 VCS 和 repo 的知识，但任何软件开发人员都应该具备这些知识。
需要考虑的是在每个开发阶段可能会发生多少新代码和多少修改。通常，冲刺/发布阶段会产生比错误修复阶段更重要的更改集。这意味着立即分支并在出现时合并较少数量的错误修复更为明智。在大多数情况下，等待分支会导致更混乱的合并。
早期分支还可以让您的错误修复更多地暴露出来，因为冲刺开发人员可以在新功能的单元和功能测试期间执行它们。更多曝光 = 更好的无错误修复。
【讨论】：
一旦您为某个版本进入功能冻结状态，您就必须执行分支，这样开发下一个版本的团队就不会继续破坏您尝试搁置的那个版本。试图进一步延迟分支只会导致更多问题。
如果您使用功能分支，那么这会变得更容易。所有修复都发生在主干中，您保留一个 RC 分支，您将从中发布，并且您可以在进行测试发布之前从主干进行批发合并。功能分支从主干合并，只有在功能准备好时才合并回主干。尽管这听起来会导致更多的合并，但它使所有合并都非常简单。
这类似于使用 DVCS 获得的工作流程，不同之处在于所有分支都清晰可见，而不是散布在开发人员的机器周围。
【讨论】：
尽可能晚地分支。
【讨论】：