情况：我们的测试版已结束，1.0 版已发布到多个客户站点。团队 A 已经忙于开发 1.1 版，该版本将进行增量错误修复和可用性调整，而另一个团队则致力于 2.0 版进行大规模更改，其中产品的核心可能已经完全重新设计。现在，为 1.1 所做的大部分更改都必须在某个时候进入 2.0，而在 2.0 分支中进行的一些错误修复实际上可能需要安排在较早的版本中。问题在于，由于 2.0 有根本的不同，因此 1.1 的任何更改都不能在没有手动转换的情况下合并，反之亦然。
我的问题：在这种情况下，将合并冲突和重复工作降至最低的最佳修订控制实践是什么？如何确保我的团队在修订控制问题上花费尽可能少的时间和精力，同时仍向客户提供定期补丁？
此处的文章（Day-to-day with Subversion）提到一种方法是使用 1.1 版本构建的数据不断更新版本 2。在文章中，这家伙说每天都要这样做。
您要阅读的部分标题为“服务员，我的行李箱里有虫子！”。这篇文章讲到一半了。
为此，我可能会依赖问题跟踪系统，并确保标记需要提交到主干代码中的每个更改。然后，您可以确保每个更改的签入注释都引用相关问题，并清楚地表达代码更改的意图，以便在尝试在主干中重新实现时易于理解。
几乎其他人都说过，但我想我会折腾我使用 SVN 在多个分支中处理开发的经验
对于我们的主打产品，我们需要同时开发 2+ 个版本。
我最初使用主干作为“主要开发”版本，每个实际版本都使用标签。分支用于新功能集的大量开发工作。后来，当我们开始同时处理 2、3 和 4 个版本时，我开始为每个版本使用一个分支。
由于我维护存储库并处理推送 QA 构建，因此我确保每天早上都进行“汇总” - 这包括从当前最低的活动分支开始合并树上的更改。因此，我最终将 1.1 的更改合并到 1.2，该更改与自上次合并以来 1.2 的任何其他更改合并到 1.3，等等。
当我提交时，我确保总是用类似的东西评论提交
合并 1.1 rev 5656-5690
这可能有点痛苦，但它有效:)
尽早合并，经常合并，并确保主线上的 QA 知道并回归/验证维护版本的每个补丁中修复的缺陷。
在后续版本中漏掉一些东西并“修复”一个错误真的很容易，让我告诉你，客户并不关心管理多个分支会变得多么复杂——那是你的工作。
确保您使用的是支持分支和合并的源代码控制系统（我曾使用过 Perforce 和 SVN，虽然 Perforce 更好，但 SVN 是免费的）。
我还相信，让一个人负责以一致的方式执行合并有助于确保它们定期发生。通常是我或我们团队中的一位资深人士。
我们在工作中处理这个问题的方式是保持主干分支作为最前沿的代码（即本例中的 2.0）。您为 1.x 代码创建一个分支，并在那里进行所有修复。对 1.x 的任何更改都应合并（如果需要，手动合并）到主干（2.0）分支。
然后，我会坚持 1.x 开发人员在该错误的票证中记录 1.x 提交的修订号和 2.0 合并的修订号。这样，如果有人忘记合并他们的更改，就会更容易注意到，并且他们必须跟踪它的事实将帮助他们记住。
这张来自 The Build Doctor 的图片捕捉到了一个关键点：只合并一个方向。
为了回答这个特定的问题，许多开发人员已经从 Subversion 转向了 Git。结帐 github.com。