手动合并发散代码的技巧答案

【问题标题】：Tips for manual merge of diverged code手动合并发散代码的技巧
【发布时间】：2010-10-10 01:35:30
【问题描述】：

我相当习惯使用 svn 进行分支和合并，通常这工作正常。然而，一个组件在两个分支中工作，并且基本上将组件带到不同的方向，因此自动合并将不起作用，并且使用超越比较显示文件大部分不同。

我尝试将一些文件拼接在一起，但结果，即使它们有效，也相当可怕。

我很想对企业说，这是不可能的。我可以看到这让他们感到沮丧，因为他们有模块 + 功能 A 和模块 + 功能 B 工作，但模块 + 功能 A + 功能 B 就目前而言没有意义。例如，功能 A 可能会删除功能 B 中的关键组件。

有没有办法尝试合并这些代码？还是module + A + B真的是module + C？

我们确实看到了这一点，但与功能 B 相比，功能 A 需要的时间范围更短，而功能 B 是长期运行项目的一部分。有没有办法避免这种情况发生？或者他们是如何构建代码以使两个功能很好地结合在一起的？

【问题讨论】：

标签： svn merge branch branching-and-merging

【解决方案1】：

获取一个文件，例如 src1.c。您可以通过这种方式构建描述合并的菱形图：

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
         \      /
        merged src1.c

其中 b1 表示第一个分支版本，b2 表示第二个分支版本。您可以比较并行差异（例如合并源和 b2 版本之间的差异，以及 b1 和原始版本之间的差异）。这可能会有所帮助。

【讨论】：

@Yuval，我认为您正在解释三路合并。 Beyond Compare 做了三路合并。我非常有信心 OP 已经知道三路合并。

【解决方案2】：

您所说的实质上是试图重新调整其中一个分支的基础。 some DVCSs 对此提供了支持，但我不知道 SVN 中对此有任何支持。

您最好的选择是选择一个分支（现在最重要的分支）并将其合并到应该相当直接的主线中。在另一个分支中，您需要从主干中提取更改并协调差异，鉴于您描述的情况，这几乎肯定不会是自动的，您可能需要花一些时间认真考虑如何在顶部实现这个分支功能的一个并入主线，但这就是并行开发的成本：事情会发生变化。

您以后如何避免这种情况？ Frequent integration.

如果您有两个团队，每个团队都有代码库 A，并且他们在 6 个月内致力于不同的功能，那么集成将非常痛苦，因为每个团队都会假设其他团队已经更改了 A。另一方面，通过每周或每月的集成构建，每个团队都应该更清楚对方正在做出哪些更改，最终集成应该会容易得多。

这就是为什么开源项目经常反对巨大的补丁，它们过时的速度惊人地快，而且没有人真正有时间正确地审查它们。另一方面，如果您将相同的贡献分解为多个独立的可消化的小部分，则您的贡献更有可能被 A) 接受和 B) 正确审查，这样它就不会导致层出不穷的缺陷。

【讨论】：