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

我正在与一家供应商合作，该供应商为linux内核提供补丁集，以便在其平台上支持android。这意味着他们的补丁串基于一个特定的linux版本，并且在他们的补丁串中包含了一些android补丁（我猜是cherry picked），它们应用于相同的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.y上的android补丁与供应商补丁完全纠缠在一起。

我的两分钱：

冲突的原因不是您选择了一些提交，而是因为一些提交正在相同的位置更改相同的文件，git无法干净地应用差异

如果更改发生冲突，您没有很多选择： a） 您可以合并并解决冲突，以使代码达到所需的状态 b）你试图通过使用诸如我们的或他们的合并策略来自动地解决冲突，这取决于你认为对你的目的更正确的。

看这里

您可以尝试的另一种方法是在更新的上游android-2.6.x上重新设置0_rel_z分支的基础

最后，你的问题不是冲突本身，而是你必须立刻处理的冲突数量。因此，我将研究如何改进您管理更新的流程，可能是更频繁地进行更新（例如，每日与每周），并在更新上游的基础上不断重新调整您的开发分支，直到您准备完成某个功能的开发

---

希望有帮助

+1个非常有趣的问题！