確實「rebase」導致衝突次數少於「merge」？

Question

偶爾我會偶然發現'git rebase'導致衝突數量少於'git merge'的情況，例如：Why does git rebase often have fewer merge conflicts than a merge?。這是否意味着git-merge <BRANCH_A> <BRANCH_B>可能會失敗，我會做git reset --hard ORIG_HEAD，然後做git-rebase <BRANCH_B> <BRANCH_A>，它會成功嗎？你能舉一個這樣的例子嗎？

Answer 1

的技術差異

想像這樣一個歷史：

A-B-C-D-E 「top-branch」 
    \ 
    F-G-H 

現在合併E到H意思是：「採取B‣H一個diff和B‣E一個diff，並找出如何結合他們」。

衍合，從另一方面意味着：

• 採取B‣F一個diff和B‣E一個diff，並找出如何將它們組合成F’
• 採取F‣G一個差異和差異的F‣F’並瞭解如何將它們合併爲G’
• 帶上G‣H的差異和G‣G’的差異，並瞭解如何組合它們到H’

所以墊底是完全一樣的合併F，然後G然後H到top-branch。

現在，這對衝突意味着什麼？

rebase方法將執行更多步驟的合併。這有利有弊。

再次基於>合併：

• 衝突可以通過應用在小（分離）的變化來避免步驟
• 做底墊的人將（可能）自己改變一個接一個並解決其中的衝突。解決衝突可能會更容易一次完成。

合併>調整基線

• 陪你一起跑有解決更多衝突的高風險變基，因爲兩個轉變到同一代碼塊在兩個不同的提交是做可能導致在兩個矛盾重整，但只有一個合併。想想H實際上是F的回覆會發生什麼。
• 即使您有相同數量的衝突，重新組裝仍然是一個更乏味的過程：您必須多次打開同一個文件以解決發生在不同提交時的衝突。
• 解決衝突可能實際上更容易進行合併，因爲您可以一次查看兩個分支的所有更改。

在我看來，rebase實際上是更糟糕的過程，雖然這可能是可能的，但我很難想象它實際上避免了衝突的情況。看起來很有可能是你的衝突只是由F中的單行更改引起的。當代碼塊在G中進一步更改時，您可能必須將所有這些更改解決爲合併中的一個衝突，但您只需解決重新分配中的單行更改。但這並沒有什麼不同，因爲衝突只會看起來更大，但應該很容易解決。