在我解释核心问题之前，让我说我真的很感兴趣将源代码控制从Subversion迁移到Git / Mercurial，如果它真的是我们问题的更好解决方案，但我真的在寻找最佳解决方案，不会给团队带来太多不必要的压力。 （换句话说，我不是在寻找“完全转储Subversion并转向Git”的答案，因为这涉及到很多颠簸和陡峭的学习曲线。）
现在已经不在了，这是我们的核心问题：
我的开发团队正在使用一个相对较大的Subversion存储库，其中所有开发都是直接在Trunk上完成的。上面提出的更快发布周期的请求导致我们将我们的工作拆分为单独的分支，每个分支在创建分支时包含Trunk的镜像，并且子团队在每个分支上并行工作。新周期是将特定分支发布到生产，然后将新更改合并到主干，并将主干更改合并到每个其他分支。
不幸的是，这已成为一个非常痛苦且容易出错的过程，我们需要找到一种更好的方法来执行我们的合并，同时考虑到分支之间的简单更改，例如代码重新格式化（我们中的一些人使用“清理代码”） “在我们的源文件上，有些没有。”
总而言之，我们需要帮助找出一种更好的合并方式，不需要我们的一个或多个开发人员花一整天时间手动解决冲突。
（对不起，如果这有点模糊或漫无目的;我很乐意根据要求澄清或提供更多细节。）
答案 0 :(得分：1)
在这里查看Subversion文档：http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html
我的建议是使用功能分支合并模式将分支合并到trunk。一次一个，从执行较少变化/伤害的那个开始。
新周期是将特定分支发布到生产中 将新更改合并到trunk中，并将trunk更改合并到每个中 其他分支。
功能分支合并模式，基本上颠倒了这些操作的顺序。
作为旁注：“清理代码”是一个好主意，只要团队中的每个人在提交之前使用 。 Subversion（或任何其他VCS）不可能知道哪些更改是针对代码行为的，哪些更改是为了美化。