2017-08-15 79 views
1

我已經提交了一個分支bug修復,櫻桃選擇提交 到分支開發。然後,我對bugfix分支進行了一次更改B,觸及代碼A周圍的代碼區域。 現在,當我合併原產地/開發回分支bug修正版 git已經指出了這些行的衝突。 這是git中的錯誤,還是設計中的故意? 我的意思是:導致該人造衝突的缺陷修復分支起源 和非常分支已經有了承諾A.git:合併後的櫻桃選擇提交的衝突

+0

不,有一些錯誤。考慮到你在提交A之前就從'develop'創建了'bugfix'分支,並且除了A和B之外沒有任何提交,這應該適用於乾淨。我假設這些文件在提交之前已經不同了,或者在更改之後(例如,在合併之前從遠程拉取)。 –

+0

是的,我幾天前分支發展,從那以後他們一直在發散。但是,承諾A開發的櫻桃挑選使相關的兩個文件相同。 –

+0

所以你回答了你自己的問題。使用它來看看它爲什麼發生:'git diff bugfix_B_SHA develop_A_SHA - file.c'。 –

回答

3

當您合併不同,櫻桃採摘承諾是不一樣的提交了更改,但新提交包含相同的更改(查看櫻桃採摘提交的散列並與原始提交進行比較)。因此,在您最終將兩個分支合併在一起時,在您的兩個分支中的任何一個分支上受櫻桃選擇提交影響的代碼的更改將導致合併衝突。實際上,對於Git來說,就好像你已經在兩個分支上以不同的方式以獨立的方式完成了更改(因爲之後你改變了櫻桃選擇的提交的代碼)。

如果在最終將它們合併到一起之前,您並未更改受兩個分支中櫻桃挑選影響的代碼,git將會看到兩個不同的提交,但具有完全相同的更改。在這種情況下,不會顯示合併衝突。

請注意,提交不僅僅是它所包含的更改。這也是您完成更改的日期,提交消息,父提交等。這是創建新提交的方式。

這就是爲什麼你應該避免使用櫻桃採摘,如果有其他方式實現你所需要的。

1

衝突只是表示分支A的尖端代碼與分支B的尖端代碼發生衝突。如果您在bugfix分支中所做的更改與最初在cherry-選擇提交您將解決這些更改。

我的意思是:導致該人造衝突起源於 修正錯誤的分支,並且非常分支已經有了承諾A.

但你也說你已經做過修正錯誤的更多的變化的變化科?該代碼不在開發中,因此衝突...