我们公司最近使用TortoiseSVN作为客户端将版本控制系统切换到SVN，以便于使用敏捷开发方法。我们的SVN存储库有多个来自主干的分支，每个sprint一个。我们通常做“保持分支最新的主干然后重新整合分支”的方法。但是，有时需要将分支中的更改移植到主干或其他分支！ （像错误修复）。我们有一个不断开发的错误修正分支（如果可能的话我想保留它一个分支，所以主干可以保持“纯粹”）。
如果我定期将一系列修订从分支合并到主干，然后在完成我们的错误修正集后重新集成分支到主干，这会有效吗？我不想双重合并。从来没有做过重新整合合并而只是继续做一系列的修改会更好吗？我们正在使用SVN 1.6。
答案 0 :(得分：6)
如果我合并了一系列修订版 然后定期分支到主干 当我们的时候重新整合分支到主干 一套错误修正完成了，这个 工作？
是的，它会起作用。
我不想双重合并。
由于您使用的是Subversion 1.6，只要svn:mergeinfo property未被篡改，Subversion就会跟踪已合并的更改，并仅合并那些尚未合并的更改。
永远不会做得更好 重新融合而不仅仅是合并 继续做一系列的修改？
你可以做任何一个。但我建议进行重新整合合并，除非您将补丁或热修复移动到主干或其他分支。
关于从分支到分支合并时的补丁或热修复的一个注意事项：如果热修复或补丁具有新对象（文件和/或目录），请注意。有时这些可能导致树冲突，在分支被释放后合并或重新集成可能会很痛苦，移动到主干，然后从主干更新另一个分支。 Subversion 1.6.x和相关客户端在合并过程中处理此问题，但较旧的客户端则不会。
答案 1 :(得分：1)
两个问题：
您是否在一个发布周期中运行多个不相关的冲刺？
您是否在每个发布周期结束时将发布标记为上次发布的生产版本？
如果您对第一个问题的回答是肯定的，那么从分支到主干的多个分支和定期合并是有意义的。如果你定期或每个版本标记版本，它可能会使多余的运行分支并将trunk作为“前沿”开发版本，包括错误修正。因人而异。