情况:我们已经过beta，并且1.0版已发布到多个客户站点。团队A已经在忙于1.1版的工作，该版本将进行逐步的错误修复和可用性调整，而另一个团队在2.0版上进行大规模更改，其中产品的核心可能已被完全重新设计。现在，对1.1所做的大多数更改都必须在某个时候进入2.0，并且实际上可能需要安排在2.0分支中进行的一些错误修复计划用于较早的发行版。问题在于，由于2.0具有根本差异，因此如果不手动转换就无法合并对1.1的更改，反之亦然。
我的问题:在这种情况下，最大程度地减少合并冲突和重复工作的最佳修订控制做法是什么？如何确保我的团队在版本控制问题上花费尽可能少的时间和精力，同时仍向客户提供常规补丁？
最佳答案
一种好的方法是修复稳定分支中的每个错误，然后将稳定分支合并到开发分支中。这是Parallel Maintenance/Development Lines模式，关键是尽早并经常合并。不频繁合并和后期合并意味着与稳定分支相比，无法识别开发分支，或者无法以相同方式重复该错误。
Subversion从1.5版开始包括合并跟踪，因此您确保同一更改集不会被合并两次，从而导致愚蠢的冲突。存在其他系统(例如Git，Mercurial，Accurev，Perforce)，使您可以进行以下类型的查询:“分支A上的哪些更改尚未合并到分支B中？并挑选您需要的修补程序到dev分支。
关于svn - 如何同时处理1.1版和2.0版？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/44566/