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

Question

我正在与一家供应商合作，他们提供了一个补丁集来支持在他们的平台上运行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补丁都包含在Android-2.6.x版本中，但我也希望所有供应商的补丁都能支持他们的平台。不幸的是，在v_rel_x.y分支中，许多v2.6.x.y+1..android-2.6.x变更集中的变更已经应用了。因此，从Android-2.6.x到o_rel_z的简单合并会创建大量冲突，这些冲突无法通过手动解决。

您有任何关于可靠地执行从Android-2.6.x合并到o_rel_z的想法吗？

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

- Bjarke Freund-Hansen

Answer 1

我的两分钱意见：

1. 冲突的原因不是你挑选了一些提交，而是因为一些提交正在更改相同位置的相同文件，Git 无法干净地应用差异。
2. 在出现冲突的情况下，你没有太多选择： a）合并并解决冲突，将代码带到期望的状态 b）尝试通过使用合并策略（如--ours或--theirs）自动解决冲突，具体取决于你认为对你的目的更正确的是什么。

请参阅此处Git 合并文档

另一种方法是尝试将您的0_rel_z分支重新基于更新的上游android-2.6.x

最后，你的问题不是冲突本身，而是你必须一次处理大量冲突。因此，我建议你查看如何管理更新的过程，可能要更频繁地进行此操作（例如每天与每周），并不断将开发分支重新基于更新的上游，直到准备完成功能的开发。

希望这有所帮助！

- Eugene Sajine