如何將功能分支應用/合併到新版本分支？

讓我們考慮一下這種情況：如何將功能分支應用/合併到新版本分支？

---A---B---C---D---E---F---G---H---I---J--- (master from upstream) 
     \     \ 
     D'--F'    J'    (releases from upstream) 
      \ 
       P---Q       (own branch)

我們希望已經合併或修補所有我們自己的分公司到J」。

當P --- Q將成爲主分支的直系後代時，我不會遇到太多麻煩。但是，在這個用例中，我得到了許多與我自己的分支中沒有被觸及的文件相關的合併衝突。在這個例子中，這些衝突源於D'--- F'部分。所以我從F'--- Q生成了一個diff，並試圖將它應用到J'上。結果：許多應用錯誤。另一種方法，git-format-patch F'--- Q然後git am -3 -k也不是一個有效的解決方案。實際上，這與合併解決方案相當。我也嘗試了rebase。再次說明：我沒有碰到的許多文件出現在重新印刷過程中。

有沒有乾淨的解決方案？

來源

2012-10-08 Rob

在處理髮布分支之前，您不應該將自己的開發重新初始化爲高手嗎？而且，從我以前在其他SCM上的經驗來看，我們應該只使用發佈分支從主服務器捕獲更改集（用於維護版本）。功能分支應該從分支進行開發（在你的情況下是主分支）而不是分支分支。這將使整個故事更容易處理 –

嗯，確切地說：我的功能分支實際上是一組內核修改的驅動程序等，組成一個Linux內核用於自己的目的，但期望的發佈質量。這就是爲什麼我將我的分支基於發佈分支而不是主分支的原因。我也是這樣做的，因爲增加了git的經驗。我只是沒想到git會抱怨我沒有碰過的文件。 – Rob

關於你的想法（改回）：我也考慮過這個問題，但決定先問這個問題，因爲一個雙重過程聽起來很複雜。將我自己的分支更新爲更新的內核版本已經夠痛苦了。 – Rob

我開始意識到由git格式補丁生成的提交數量遠遠超過嚴格必要的。處理這個並格式化更小的提交範圍導致更好地處理git迭代。爲了解釋發生了什麼，我擴展了圖：

---A---B---C---D---E---F---G---H---I---J--- (master from upstream) 
    \ \     \ 
    \ D'--F'    J'    (releases from upstream) 
     \  \ 
     M---N---P---Q       (own branch)

M-N是以前的提交，基於主。 p是一個合併提交，所以

git format-patch F'..Q

導致貼片系列歷史更深（我的情況：約60），並且很奇怪git am的迭代。當使用格式補丁P --- Q時，我可以獲得約。 30次提交（事實上，P --- Q是一個簡化）。現在git迭代結果git mergetool步驟與P提交之後的提交有明確的關係，並且可以管理。

來源

2012-10-09 08:06:09 Rob

如何將功能分支應用/合併到新版本分支？

回答

相關問題