當在要精挑細選的材料發生衝突,Git會做同樣的事情總是這樣:
- 看那合併基礎版本;
- 看看
HEAD
版本;和
- 看待合併版本。
如果設置merge.conflictStyle
到diff3
(我),你會看到所有三個版本,而不是僅僅這三個中的兩個,在衝突地區。我發現這有助於看到Git看到了什麼。
那麼,爲什麼我從A顯示了用C看到任何東西,當它沒有B中直接加入,我採摘櫻桃的提交?我猜這與衝突有關,因爲沒有其他A來自衝突線周圍的東西。
這是正確的:這個問題是混帳必須找到一個合併基礎承諾,以決定「你改變了」 - 這是合併基礎比較當前的結果或HEAD
承諾和「他們改變了什麼「,這是將合併基礎與」他們的「提交進行比較的結果。
你在這一切的開頭提到的「分支」:
我有被關閉分支A.創建我使分支B中的幾次提交,我想摘櫻桃支路B進入分支C(與A相似)。
但事實上,Git大多根本不關心分支。 Git只關心提交 - 分支主要與Git有關,分支名稱允許Git查找單個提交。它有助於繪製出實際的提交(如果你喜歡,包括分支的標籤,讓我們-和Git,發現這些提交):
H--I--J <-- branch-B
/
...--E--F--G <-- branch-A
\
K--L <-- branch-C
我從全棉布製成該圖了,它可能看起來像你的圖很小,但它現在可以讓我們說明奇怪的方式git cherry-pick
在Git中標識合併基提交。
如果我們在「branch-C」上,因爲git status
可能會說,我們的HEAD
提交是提交L
,分支-C的提示。如果我們再運行git cherry-pick <hash-of-commit-I>
,GIT中使得這些分配:
- 合併基礎=提交ħ
- HEAD或
--ours
=提交大號
--theirs
=提交我
git會然後DIFF(在git diff
)提交H
對提交I
看到他們做了,那什麼是我們想櫻桃採摘,但也差異承諾H
對提交L
,看看有什麼我們變化,尋找衝突。
如果有是衝突,Git會爲我們展示了雙方都在合併基礎版本H
,實際上並沒有向我們展示了合併基礎版本H
本身。這可能包括的東西,我們並不想:東西,我們通過進入「向後」從H
到L
「刪除」。有混帳顯示了合併基礎版本H
還有,我們可以看到,我們「刪除」的東西,我們不想要的,所以我們應該「保持刪除」解決合併衝突時。