一、什么是合并（Merge）

在 Git 中，合并是將兩條獨(dú)立的開發(fā)線（分支）的修改整合到一起的操作。當(dāng)你執(zhí)行 git merge 時，Git 需要決定如何將兩個分支的代碼變更合并為一個最終結(jié)果。

二、快進(jìn)合并（Fast-Forward Merge）

在了解三方合并之前，先了解最簡單的合并方式。

場景

A --- B --- C (main)
              \
               D --- E (feature)

如果 main 分支在你創(chuàng)建 feature 分支后沒有任何新提交，合并時 Git 只需要把 main 的指針直接移動到 feature 的最新提交即可：

A --- B --- C --- D --- E (main, feature)

這就是快進(jìn)合并，不會產(chǎn)生新的合并提交。

特點(diǎn)

• 不產(chǎn)生合并提交（merge commit）
• 歷史記錄是一條直線
• 只有在目標(biāo)分支沒有新提交時才會發(fā)生

三、三方合并（Three-Way Merge）

什么時候觸發(fā)

當(dāng)兩個分支都有各自的新提交時，Git 無法簡單地快進(jìn)，必須執(zhí)行三方合并：

A --- B --- C --- F --- G (main)
              \
               D --- E (feature)

此時 main 有了 F、G 兩個新提交，feature 有了 D、E 兩個新提交，Git 需要把兩邊的修改合在一起。

三方合并的"三方"是什么

三方合并涉及三個版本：

為什么需要共同祖先

假設(shè)某個文件的某一行：

• 在共同祖先中是 x = 10
• 在 main 中是 x = 10（沒改）
• 在 feature 中是 x = 20（改了）

如果沒有共同祖先作為參照，Git 只看到 main 是 x = 10，feature 是 x = 20，無法判斷應(yīng)該用哪個。

有了共同祖先，Git 的判斷邏輯就很清晰：

• 共同祖先是 x = 10，main 也是 x = 10 → main 沒改
• 共同祖先是 x = 10，feature 是 x = 20 → feature 改了
• 結(jié)論：采用 feature 的修改

四、共同祖先（Merge Base）

定義

共同祖先是兩個分支在提交歷史中最近的共同節(jié)點(diǎn)。它代表了兩個分支"分道揚(yáng)鑣"的那個時間點(diǎn)。

圖示

         E --- F (feature-A)
        /
A --- B --- C --- D (main)
        \
         G --- H (feature-B)

• feature-A 和 main 的共同祖先是 B
• feature-B 和 main 的共同祖先是 B
• feature-A 和 feature-B 的共同祖先也是 B

查找共同祖先

git merge-base <branch1> <branch2>

這個命令會輸出共同祖先的 commit SHA。

復(fù)雜場景：多次合并后的共同祖先

A --- B --- C --- D --- M1 --- E (main)
        \             /
         F --- G --- H (feature)

如果 feature 曾經(jīng)被合并到 main（M1），之后 feature 又繼續(xù)開發(fā)，那么再次合并時：

• 共同祖先不再是 B，而是 H（上次合并時 feature 的狀態(tài)）

Git 會自動找到最近的共同祖先，確保只合并上次合并之后的新變更。

五、三方合并的決策規(guī)則

對于文件中的每一處差異，Git 按以下規(guī)則決定最終結(jié)果：

規(guī)則總結(jié)

1. 只有一方修改 → 自動采用修改方的版本
2. 雙方做了相同修改 → 自動采用（無沖突）
3. 雙方做了不同修改 → 產(chǎn)生沖突，需要人工解決
4. 雙方都沒改 → 保持原樣

六、沖突（Conflict）

什么時候產(chǎn)生沖突

當(dāng)同一處代碼兩個分支都做了不同的修改時，Git 無法自動決定用哪個版本，就會標(biāo)記為沖突。

沖突標(biāo)記

<<<<<<< HEAD
// 當(dāng)前分支（ours）的代碼
int count = getCount();
=======
// 目標(biāo)分支（theirs）的代碼
long count = getCount();
>>>>>>> feature

解決沖突

1. 手動編輯文件，選擇保留哪個版本（或合并兩者）
2. 刪除沖突標(biāo)記（<<<<<<<、=======、>>>>>>>）
3. git add <file> 標(biāo)記為已解決
4. git commit 完成合并

七、合并提交（Merge Commit）

三方合并完成后，Git 會創(chuàng)建一個特殊的合并提交，它有兩個父提交：

A --- B --- C --- F --- G --- M (main)
              \             /
               D --- E ----  (feature)

M 就是合并提交，它的兩個父提交分別是 G（main 的最新）和 E（feature 的最新）。

查看合并提交的父提交

git log -1 --format="%P" <merge_commit>

輸出兩個 SHA，第一個是當(dāng)前分支的父提交（ours），第二個是被合并分支的父提交（theirs）。

注：

博客：

https://blog.csdn.net/badao_liumang_qizhi

八、實(shí)際場景分析

場景：從舊分支合并到已更新的目標(biāo)分支

時間線：
1月：dev 上有人把 Integer 改為 Long
3月：你從 master（還是 Integer）拉出 feature 分支
5月：你把 feature 合并到 dev

合并時的三方對比：

Git 判斷：你沒改這行，dev 改了 → 采用 dev 的 Long。

場景：你修改了同一行附近的代碼

如果你在 feature 分支修改了 Integer count = ... 這行附近的代碼（比如上下幾行），Git 可能會：

• 把你修改的部分保留
• 把 dev 修改的部分也保留
• 如果兩者修改了同一行 → 產(chǎn)生沖突

場景：你的分支不是從 dev 拉的

如果你從 master 拉分支，而 master 和 dev 的代碼狀態(tài)不同，合并到 dev 時共同祖先可能是很早之前的提交，導(dǎo)致大量差異需要合并，增加了自動合并出錯的風(fēng)險(xiǎn)。

九、合并策略選項(xiàng)

recursive（默認(rèn)）

Git 默認(rèn)使用 recursive 策略進(jìn)行三方合并。當(dāng)存在多個共同祖先時，它會遞歸地合并這些祖先來構(gòu)造一個"虛擬祖先"。

ours

git merge -s ours feature

完全忽略對方的修改，保留當(dāng)前分支的所有內(nèi)容。

theirs（通過選項(xiàng)實(shí)現(xiàn)）

git merge -X theirs feature

沖突時自動選擇對方的版本。

十、最佳實(shí)踐

1. 頻繁同步：定期將目標(biāo)分支（dev/main）合并到你的 feature 分支，減少最終合并時的差異
2. 從正確的分支拉取：如果要合并到 dev，就從 dev 拉分支，而不是從 master
3. 小步提交：每次提交的改動盡量小且聚焦，減少沖突范圍
4. 合并前先拉取最新：git fetch + git merge 確保本地是最新狀態(tài)
5. 合并后立即驗(yàn)證：編譯、運(yùn)行測試，確保合并結(jié)果正確

十一、總結(jié)

三方合并的核心思想：

通過共同祖先作為參照基準(zhǔn)，判斷每一處差異是"誰改的"，從而自動決定最終結(jié)果。只有當(dāng)雙方都改了同一處且改法不同時，才需要人工介入。

理解了這個原理，你就能理解為什么合并后代碼會"自動變化"——不是 Git 出了問題，而是它正確地執(zhí)行了三方合并的邏輯。

以上就是Git三方合并策略詳解的詳細(xì)內(nèi)容，更多關(guān)于Git三方合并策略的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論