手动合并分歧代码的技巧

Question

我很熟悉使用svn进行分支和合并，通常情况下都能正常工作。然而一个组件在两个分支上开发时基本上走向了不同的方向，所以自动合并无法完成，使用Beyond Compare显示文件差异非常大。

我已经尝试拼接一些文件，但即使它们能正常工作，结果也相当可怕。

我倾向于告诉业务部门这个问题无法解决。我可以看出这会让他们非常沮丧，因为他们已经将模块+功能A和模块+功能B结合起来了，但是模块+功能A+功能B在目前的状态下毫无意义。例如，功能A可能会删除功能B中的关键组件。

有没有办法尝试合并这样的代码？还是说模块+A+B真的变成了模块+C？

我们早就看到了这种情况，但是需要更快地推出功能A，而功能B则是长期项目的一部分。有没有方法可以避免这种情况发生？或者有没有方法可以构建代码结构，使得两个功能能够完美结合？

- Jeremy French

Answer 1

你提到的本质上是尝试变基其中一个分支。一些分布式版本控制系统（DVCS）支持此功能，但我不知道SVN是否支持这种操作。

你最好选择其中一个分支（现在最重要的那个）并将其合并到主干线路中，这应该相对直接。在另一个分支中，您需要从主干中拉取更改并协调差异。鉴于您所描述的情况，这几乎肯定不会自动完成，您可能需要花费一些时间考虑如何在已合并到主干线中的基础上实现这些分支功能，但这就是并行开发的代价：事情会发生变化。

将来如何避免这种情况？频繁集成。

如果你有两个团队，每个团队都拥有代码库A，并且他们在不同的功能上工作了6个月，那么集成将非常痛苦，因为每个团队都会对A做出假设，而另一个团队已经改变了。另一方面，通过每周或每月的集成构建，每个团队应该更加清楚另一个团队正在进行哪些更改，最终的集成应该会更容易。

这就是为什么开源项目通常反对巨大的补丁，它们很快就会过时，没有人真正有时间适当地审查它们。另一方面，如果您将相同的贡献分成多个小的可消化的部分，这些部分可以独立存在，那么您的贡献更有可能被接受和适当地审查，以避免无尽的缺陷流。

- zacherates

Answer 2

拿一个单独的文件，比如src1.c。 你可以构建一个描述合并的钻石图：

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

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

- Yuval F

---

@Yuval，我认为你正在解释三方合并。Beyond Compare可以进行三方合并。我非常有信心OP已经知道了三方合并。 - Lieven Keersmaekers