Git：僅合併分支所做的更改

G---H    // Release Branch 
/
/
A---B---E---F--- // master 
    \ 
    \ 
     C---D---  // bug fix branch

根據我們對項目的特殊需求，上述情況發生的情況非常普遍。我們有一些提交的主/開發分支。然後我們得到一個錯誤報告，並開始修復錯誤分支（提交上面的C和D）。同時在開發分支中發生更多的提交。接下來我們被告知我們需要爲客戶創建一個發佈版本，其中不能包含上面提交的B，E和F提交的更改，但它應該包含錯誤修復。Git：僅合併分支所做的更改

因此，在更改B應用之前，我們分支了dev，但是在這個版本分支中修復bug的最佳方法是什麼？如果我執行分支合併，它將包含B中所做的更改，這是我不想要的。我可以執行提交C和d的摘櫻桃，但我讀了櫻桃採摘並不總是一個好主意based on this answer主要是因爲我的回購會再看看這樣的：

G---H---C'---D'--- // Release Branch 
/
/
A---B---E---F---  // master 
    \ 
    \ 
     C---D---  // bug fix branch

所以C「和d」顯示爲完全新的提交與不同的sha-1 ID作爲C和D.這真的是一件壞事嗎？這會導致什麼問題？是否有更好的方式將錯誤修復分支中的更改導入發佈分支？

來源

2011-07-06 DaveJohnston

使用櫻桃挑選沒有真正的危險，特別是如果您不打算將release分支合併到master。

一般來說，您可以通過將錯誤修復基於您要合併修補程序的所有分支中包含的提交中的錯誤修復來防止出現問題。在開發git本身時，通過將所有錯誤修復合併到maint分支（即僅接收修復的當前穩定系列），然後定期將其合併到master中來實現。這樣，解決方案無處不在，並且合併是理智的。

來源

2011-07-06 11:27:42

如果我將發佈分支合併回主版本，會有什麼危險？在我所做的圖中，改變H最終需要被應用回主分支。 – DaveJohnston

好吧，如果您不將錯誤修復分支合併到主服務器中，則沒有問題。如果你這樣做了，你可能會得到比你更多的衝突（如果兩個分支以相同的方式修改代碼的這些部分，並在其上添加一些不同的更改）。「危險」是多餘的，真的......這意味着你必須手動修復一堆衝突，並且這兩個提交會在你的歷史記錄中顯示兩次（使用不同的提交ID）。 –

This文章建議，而不是合併兩個分支，你會rebase他們在哪裏git只會rebase非重複提交。

但在挑肥揀瘦的代替，你可能會考慮只重訂的分支：

rebase --onto release B bug

其中release是發佈分支和bug是錯誤的分支。

然後你得到類似

  C'---D' //Bug branch  
     /
    /
    G---H // Release Branch 
/ 
/
A---B---E---F---  // master

但是，這將意味着，當你想將被應用的bug修復掌握，你將需要合併的bug與掌握，從而導致所有的版本也將改變被添加到主。

這取決於你決定什麼最適合你。

請注意，您不應該將已經爲pushed的分支重新分配給其他分支，因爲它會爲他們創建一個混亂。

來源

2011-07-06 11:20:40 Ikke

通過它的外觀，所有這些提交被推送到遠程回購。在這種情況下，不宜採用rebase。 – Sailesh

在我看到此評論之前添加了該部分。 – Ikke

注意：如上所述，櫻桃採摘在這裏是可以接受的。
它的主要缺點是：

在合併的情況下，你會因爲重複的承諾
請參閱「Git cherry pick and datamodel integrity」
忽略函數依賴得到衝突。
請參閱「How to merge a specific commit in git」。

你的情況：

沒有必要合併回去。
如果您確定C和D不是基於B中介紹的代碼，請在需要它們的地方挑選它們。

來源

2012-11-19 11:35:49 VonC

Git：僅合併分支所做的更改

回答

相關問題