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.y上的android补丁完全与供应商补丁纠缠在一起。

Answer 1

我的两分钱：

冲突的原因并不是你有一些提交的提交，而是因为一些提交正在改变相同位置的相同文件而git不能干净地应用diff。
如果更改有冲突，您没有太多选择： a）您合并并解决冲突，使代码处于理想状态 b）您正试图通过使用合并策略（例如--ours或 - ）合并来自动解决冲突，具体取决于您认为更适合您的目的。

请参阅此处Git merge documentation

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

最后，你的问题不是他们自己的冲突，而是你必须立即处理的数量。所以我会看一下改进流程如何管理更新，可能会更频繁（例如每天与每周），并在更新上游之前不断重新设置开发分支，直到您准备好完成功能的开发。

希望有所帮助！

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

1 个答案: