假设您的软件现有版本有几个维护分支。一些开发人员正在对维护分支进行直接更改，并定期合并到主干中。现在，在主干代码行中进行了广泛的重构，计划在即将发布的主要版本中进行。但这会使维护分支与trunk中的代码根本不兼容，因为它们可能依赖于不再存在的代码，例如。
你如何在实践中处理这种情况？
答案 0 :(得分：22)
我认为分支维护开发人员有责任将适当的更改合并到主干的当前状态。有几种可能性：
案例1和案例2是通常的维护发展路径。案例3是您正在考虑的情况，其中主干代码不能以任何形式接受维护补丁。如果开发人员无法自己确定主干中是否存在同样的问题，那么他应该在问题跟踪系统中输入问题。此问题将指导主干开发人员考虑维护分支中修补程序的原因以及是否仍存在相同的缺陷。在主干中为可能的缺陷输入新问题应该是维护开发人员的最后手段。
让维护开发人员尝试将补丁应用于更新的主干的一个好处是增加他们对新代码库的熟悉程度。最终，他们将耗尽维护工作，并需要使用新的主干。至少具有基本的熟悉程度将是非常有益的。
答案 1 :(得分：3)
这最终是关于团队沟通的问题，而不是简单的分支/合并问题。
与所有这些情况一样，第一步是意识到你遇到了问题。这是你已经完成的事情。
然后，您需要提醒整个团队注意这个问题。
一旦你完成了，我认为有两种不同的途径：
如果不经常使用维护分支，说发布的代码相当成熟且没有错误，您可以决定冻结代码。每个开发人员必须在32月9日之前完成他/她正在处理的工作，并将这些更改合并到主干中。然后应该关闭或冻结分支。然后，可以在主干中继续工作，并且可以发布新软件。
如果分支机构中有频繁或紧急的更改和修复，则此问题会更复杂。仍然需要冻结代码，否则主干将被多次破坏。但在这里，开发人员仍然需要在过渡期间解决问题并将其交给客户。我建议在主干代码冻结后分支中的每个更改都应该记录在错误跟踪数据库中（必须在每种情况下），并特别指出这是在分支N中修复但尚未合并到主干。这需要仔细记录，以便记住每个相关细节。
在重构主干之后，但在清理，修改，标记和释放主干之前，请检查错误数据库，特别是固定在分支中但不是主干的项目。它们仍然相关吗？现在是时候再次更改代码，如果有必要的话。这可能意味着短暂的双重工作，但希望代码现在更易于维护。
修复所有已知问题后，可以发布新版本，并可以关闭旧版本。
答案 2 :(得分：2)
我能够想到的唯一答案是在开始重构之前创建一个维护主干分支。您维护这个新分支就像它是一个主干一样，正常地将更改与发布分支合并。展望未来，您必须小心混合来自新旧源的变化。
另一种选择是尝试类似MolhadoRef（blog article about MolhadoRef and Refactoring-aware SCM）的内容，如果您能找到满足您需求的可立即生产的等效系统。理论上，这是重构感知源控制。我有一段时间没有调查过，但最后我还记得，它远不是一篇研究论文和概念验证。
答案 3 :(得分：2)
在实践中，您可能需要做额外的工作才能使新的更改向后兼容。
步骤1：开始重构组件。对于每个步骤，保留旧接口，但让它将调用迁移到新实现。请注意，在构建新接口/ API时，可以通过几个步骤完成此操作。单元测试应能够验证从旧版本到新版本的迁移是否正常工作，但此步骤很可能仍会产生测试/ QA开销。
第2步：新版本正在投入生产;确保每个人都知道。此时，旧版本没有添加任何新功能，所有新的（或更改的）呼叫者都使用新版本。
步骤3：查找调用旧界面的所有内容（使用工具执行此操作），并更改所有内容以调用新界面。这也可能导致大量的测试/ QA开销。但是，每个调用者可以一次一个地提交/释放。
步骤4：此时，新版本已启用，并且没有任何呼叫者可以访问旧版本。安全删除。
请注意，如果API是公开的，并且您无法控制调用它的人（例如Microsoft公司），那么您可能永远无法通过第2步。
这个过程可能很慢，需要大量的纪律，沟通和测试。但是，如果替代方案永远在追赶/整合，那么这可能是一个合理的选择。
答案 4 :(得分：2)
鉴于修复错误的大部分成本是重现问题并测试修复。您是否可以编写一个适用于所有分支的自动化测试，即使代码修复必须针对每个分支进行不同的操作？
答案 5 :(得分：1)
当您的维护分支机构不再与主干线兼容时，是时候为此目的创建新的分支机构了。也就是说，在大项目开始时，您确保所有开发人员都知道主干线中将出现新功能，以便他们可以更好地选择实施修复的位置。据推测，如果主干中发生的代码变化非常严重，导致维护不可支持，那么维护应该包含在主干中。
答案 6 :(得分：1)
创建一个维护分支，让它充当trunk和版本分支之间的缓冲区。
版本分支的更改进入维护分支，然后只有在可以的情况下才会进入主干，反之亦然。
但是，我不认为有一颗银弹。随着分支越来越分散，它们将变得不兼容，因此你必须考虑你将支持它们多久。否则，你可能不止一次修复错误，但对于各个分支来说略有不同。答案 7 :(得分：1)
这可能是一项非常耗费精力的建议，但我想到的第一件事就是将所有东西合并到后备箱。每个人的更改都会合并回主干副本并将它们保存在一起。然后，根据你的需要在行李箱上重构。现在你有一个工作主干，所有修复程序放在一起。
不幸的是，这意味着维护分支中的任何修复都需要被抛到一起并进入中央主干。我意识到这将是一项很多工作，但我认为这将允许重构所有内容，并且维护分支的任何改进都属于主分支。我可能对此很天真，但我还没有真正参与过一个生产项目，也不知道维护分支上究竟是什么。我认为这将使行李箱完全更新，并且所有维护改进都将集成到行李箱中。
我认为这样做可以最大限度地提高所有分支的质量，并使重构遍及重构后分支的所有分支。这也是将您的团队聚集在一起进行所有合并的好方法。
答案 8 :(得分：1)
我看到两种不同的解决方法：
1
主干的重大变化（如重大重构）不应该在主干中完成。它们应该在一个分支中完成，并在它们足够稳定时合并回主干。
对主干的更改应定期与其他维护分支合并。在稳定时将重构合并到主干的原因是因为这些将被合并到维护分支中。但是，如果没有机会使这些变化稳定，那么选项2会更好。
在对维护分支进行更改后，可以将它们合并回主干。
2
创建维护分支的一个分支（每个分支一个分支）。这将用于将主干与每个维护分支合并。 （注意，应使用SVN外部或等效物来限制维护分支的数量。）
在主干中进行所有重构并将其合并到维护分支的分支中。当您释放或认为主干是稳定的时，然后将维护版本的这些分支合并回各自的分支。然后可以将它们合并回主干。
实际上，每个维护分支都成为“子主干”。
请注意，此方案强调了未来维护和前期维护之间的权衡。您在代码中拥有的分支和差异越多，就需要进行更多的前期维护。好的部分是增量维护更容易。
答案 9 :(得分：0)
我只能回应其他人所说的话，同时强调补丁队列可以成为a $$的真正痛苦。
如果你有一个预定义（和铁板）合并窗口，你应该只有两个星期的地狱来处理。
答案 10 :(得分：0)
您是否必须 正在处理许多分支？
干线上的工作是否仅在启动时启动，因为项目计划表示当前版本已准备好发货，因此已发货？
您是否有很多维护分支机构，因为客户因某些原因拒绝升级到最新版本？如果是这样解决原因。
在下一个主要版本太大之前，你是否有太多的旧版本？
您是否向不会升级维修费用的客户收取费用，因为它会花费更多？
对评论的回应：
Microsoft仍支持Windows XP 即使Vista出局
非常正确，但即使XP SP3已经用完，微软仍然不支持Window XP SP1。
这不是黑白的，即使你不能停止支持旧版本，你也许可以减少你支持的旧版本的数量。问题是销售/支持喜欢说是，但是开发会带来痛苦，所以你需要让你的销售/支持人员站在一边。
答案 11 :(得分：0)
我认为您最好的选择是进行迭代重构。而不是在私人分支上的一个大镜头中进行所有重构，一次一个阶段。在分支上进行一些更改，然后当您知道它们是稳定的时，将它们合并到主干。在其他分支机构工作的开发人员将负责不断保持其分支机构与主干保持同步。
经常合并一小组更改比合并大小不同的大型分支要少得多。你合并的次数越多，你最终要做的工作就越少。
答案 12 :(得分：0)
在我们的项目中，我们主要不修复版本维护分支中的更改。如果有错误和
答案 13 :(得分：0)
作为Greg pointed，有几种可能的情况。
我添加了一个需要手动合并的情况（2.5），但是由于你已经将一个方法从其原始位置移开然后应用了一些更改，因此很难合并，特别是如果“基本”代码也在“维护”分支中进行了修改。这并不像听起来那么罕见，实际上将方法移动到不同的位置并应用小修复是很常见的。
我们开发了一个名为Xmerge（交叉合并）的工具，这是实现重构感知合并的第一步。它还不是自动的，但它有助于处理涉及移动代码的严格合并。 It's described here已经集成在Plastic SCM 2.7中。
我们正在努力：自动移动检测，并且能够“交叉合并”到多个目标文件（您将代码移动到另一个文件，这也很常见）。