合并来自上游分支卖主分支，其中vendor分支包含上游的一个子集提交

Question

我与他们为了支持自己的平台上Android提供了一个补丁集到一个Linux内核的供应商合作。这意味着他们将他们的补丁串安装在特定的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补丁android-2.6.x版本，但是我也希望所有厂商的补丁支持他们的平台。不幸的是，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修补程序完全与供应商补丁纠缠在一起。

Answer 1

我的两分钱：

1. 冲突的原因不在于你有一些提交樱桃采摘，但由于某些提交的正在改变在同一地方同一文件和Git不能应用比较干净。
2. 如果发生冲突的更改，您没有多少选择： a）您合并并解决冲突以将代码置于所需状态 b）您试图通过使用合并策略进行合并来自动解决冲突，例如 - - 或者 - 他们根据你认为更适合你的目的。

看到这里Git merge documentation

，你可以尝试另一种方法是重订更新的上游的Android 2.6.x的

最后的顶部您0_rel_z分支，你的问题是不冲突他们，自我，但是你必须一次处理它们的数量。所以我想看看你改善如何管理更新的过程中，可能使这个更经常（每天每周VS，例如），并不断衍合上更新上游的顶部您的开发分支，直到你准备好最终确定功能的开发。

希望有帮助！