从上游分支合并到供应商分支，其中供应商分支包含上游提交的子集

Question

我正在与一家供应商合作，该供应商为 Linux 内核提供补丁集，以便在其平台上支持 Android。这意味着他们的补丁串基于特定的 Linux 版本，并且在他们的补丁串中包含了一些 Android 补丁（我假设是精心挑选的），这些补丁适用于相同的 Linux 版本。

因此，当导入到 git 以及我们在顶部应用的更改时，历史记录看起来像这样：

     v2.6.x.y                          v_rel_x.y      o_rel_z
l--l--l---------v--v--a--v--a--a--v--v--v--------o--o--o

其中 l 是 linux 提交，v 是供应商提交，a 是 android 提交，o 是我们的提交。

让事情变得复杂的是，基于相同 Linux 内核版本的 android git 内核源代码是完全独立的，如下所示：

     v2.6.x.y      v2.6.x.y+1
l--l--l---------l---l
       \             \           android-2.6.x
        \             a--a--a--a--a
         \
          \                       v_rel_x.y      o_rel_z
           v--v--a--v--a--a--v--v--v--------o--o--o

现在，我想在 android-2.6.x 版本中包含所有 android 补丁，但是我也想要所有供应商都提供补丁来支持他们的平台。不幸的是，v2.6.x.y+1..android-2.6.x 变更集中的相当多的更改已经应用于 v_rel_x.y 分支。因此，从 android-2.6.x 到 o_rel_z 的简单合并会产生大量冲突，而这些冲突根本无法手动解决。

你知道如何可靠地执行从 android-2.6.x 到 o_rel_z 的合并吗？

是的，每个分支上确实有大量的提交，并且 v_rel_x 上的 android 补丁.y 与供应商补丁完全纠缠在一起。

Answer 1

我的两点意见：

1. 冲突的原因不是你挑选了一些提交，而是因为一些提交正在相同的位置更改相同的文件，而 git 无法干净地应用差异。
2. 如果发生冲突的更改，您没有太多选择：
   a) 合并并解决冲突以使代码达到理想的状态
   b) 您尝试通过使用诸如 --ours 或 --theirs 之类的合并策略进行合并来自动解决冲突，具体取决于您认为更适合您的目的。

请参阅此处 Git 合并文档

您可以使用的另一种方法尝试是在更新的上游 android-2.6.x 之上重新调整 0_rel_z 分支的基础。

最后，您的问题不是冲突本身，而是您必须立即处理的冲突数量。因此，我会考虑改进管理更新的流程，可能会更频繁地进行更新（例如，每天与每周），并在更新上游的基础上不断重新调整您的开发分支，直到您准备好完成一项功能的开发。

希望有帮助！