合併來自上游分支賣主分支，其中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，例如），並不斷衍合上更新上游的頂部您的開發分支，直到你準備好最終確定功能的開發。

希望有幫助！