情况：我们已经没有测试版，1.0版已经发布到多个客户站点。 A团队已经忙于1.1版，它将进行增量错误修正和可用性调整，而另一个团队正在使用版本2.0进行大规模更改，其中产品的核心可能已经完全重新设计。现在，1.1的大部分更改都必须在某些时候进入2.0，并且2.0分支中的一些错误修复实际上可能需要安排在早期版本中。问题在于，由于2.0存在根本差异，因此无需手动转换即可合并1.1中的更改，反之亦然。
我的问题：在这种情况下，最小化合并冲突和重复工作的最佳版本控制实践是什么？如何确保我的团队在修订控制问题上花费尽可能少的时间和精力，同时仍然向客户提供定期补丁？
答案 0 :(得分：9)
一个好方法是修复稳定分支中的每个错误并将稳定分支合并到开发分支中。这是Parallel Maintenance/Development Lines模式，关键是尽早合并。不经常和晚合并意味着开发分支与稳定分支相比是无法识别的，或者错误不能以相同的方式重复。
Subversion包括自版本1.5以来的合并跟踪，因此您可以确保相同的更改集未合并两次，从而导致愚蠢的冲突。存在其他系统（例如Git，Mercurial，Accurev，Perforce），使您可以查询类型“分支A上的哪些更改尚未合并到分支B中？”和樱桃 - 挑选你需要的修补程序到开发分支。
答案 1 :(得分：3)
文章here（与Subversion的日常）提到一种方法是使用版本1.1版本中的数据不断更新版本2。在文章中，这家伙说每天都这样做。
您想要阅读的部分标题为“服务员，我的行李箱中有一个错误！”。这篇文章大约有一半。
答案 2 :(得分：1)
为此，我可能会依赖问题跟踪系统，并确保标记需要提交到主干代码中的每个更改。然后，您可以确保每个更改的签入注释引用相关问题，并明确表达代码更改的意图，以便在尝试在主干中重新实现时可以轻松理解。
答案 3 :(得分：1)
几乎所有人都说过，但我想我会在处理使用SVN在多个分支机构中进行开发的经验
使用我们的主要产品，我们需要同时开发2个版本。
我最初使用主干作为“主要开发”版本，每个实际版本都使用标签。分支用于新功能集的大量开发工作。然后，当我们开始处理2,3和4版本时，我开始为每个版本使用分支。
由于我维护了存储库并且还处理了推送QA版本，因此我确保每天早上都进行“汇总” - 其中包括从最低的当前活动分支开始合并树中的更改。所以我最终将1.1中的变化合并到1.2中，与上次合并后的1.2中的任何其他变化合并为1.3，等等。
当我提交时，我确保始终使用类似
的内容来评论提交合并1.1 rev 5656-5690
这可能有点痛苦，但它有效：）
答案 4 :(得分：0)
早期合并，经常合并，并确保主线上的质量保证知道并回归/验证每个维护版本补丁中修复的缺陷。
很容易让一些东西漏掉并在后续版本中“修复”一个错误，让我告诉你，客户并不关心管理多个分支机构会有多复杂 - 这是你的工作。 / p>
确保您使用的是支持分支和合并的源代码控制系统（我有Perforce和SVN的经验，而Perforce更好，SVN是免费的）。
我还认为让一个人负责以一致的方式执行合并有助于确保他们定期发生。这通常是我或我们团队中的一位资深人士。
答案 5 :(得分：0)
我们在工作中处理这个问题的方法是将trunk分支保持为最前沿的代码（在本例中为2.0）。您为1.x代码创建一个分支，并在那里进行所有修复。对1.x的任何更改都应合并（手动，如果需要）到trunk（2.0）分支。
然后我会坚持认为1.x开发人员会记录1.x提交的修订号和该错误的故障单中2.0合并的修订号。这样，更容易注意到是否有人忘记合并他们的更改，并且他们必须跟踪它的事实将有助于他们记住。
答案 6 :(得分：0)
在构建医生的this picture中捕获了一个关键点：仅合并一个方向。
答案 7 :(得分：0)
为了回答这个具体问题，许多开发人员已经从Subversion切换到Git。结帐github.com。