android - 从上游分支 merge 到供应商分支，其中供应商分支包含上游提交的子集

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 是我们的 promise 。

复杂的是基于同一个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 的简单 merge 会产生大量冲突，这些冲突根本无法手动解决。

您是否知道如何可靠地执行从 android-2.6.x 到 o_rel_z 的 merge ？

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

Answer 1

我的两分钱:

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

请参阅此处 Git merge documentation

您可以尝试的另一种方法是将您的 0_rel_z 分支 rebase 到更新的上游 android-2.6.x 之上

最后，您的问题不是冲突本身，而是您必须同时处理的冲突数量。所以我会看看如何改进你管理更新的过程，可能是更频繁地进行(例如，每天或每周)，并不断地将你的开发分支重新定位在更新上游之上，直到你准备好完成功能的开发。

希望对您有所帮助!