Git

git-merge 最後更新於 2.54.0

名稱

git-merge - 將兩個或多個開發歷史合併在一起

概要

git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
	[--into-name <branch>] [<commit>…]
git merge (--continue | --abort | --quit)

描述

將指定提交的變更（自其歷史紀錄與當前分支分歧點算起）併入當前分支。此命令被 git pull 用於併入來自另一個儲存庫的變更，也可以手動使用來將變更從一個分支合併到另一個分支。

假設存在以下歷史紀錄，且當前分支為 master

          A---B---C topic
         /
    D---E---F---G master

接著執行 git merge topic 將會重放 topic 分支自從與 master 分歧（即 E）以來，直到當前提交（C）所做的變更，並將結果記錄在一個新的提交中，同時包含兩個父提交的名稱以及使用者描述變更的紀錄訊息。在操作前，ORIG_HEAD 會被設為當前分支的頂端（G）。

          A---B---C topic
         /         \
    D---E---F---G---H master

若存在無法自動解決的衝突，或者在啟動合併時提供了 --no-commit，則合併會停止。此時您可以執行 git merge --abort 或 git merge --continue。

git merge --abort 將會中止合併流程並嘗試重構合併前的狀態。然而，如果合併開始時有未提交的變更（特別是如果這些變更在合併開始後被進一步修改），git merge --abort 在某些情況下將無法重構原始（合併前）的變更。因此

警告	不建議在有非瑣碎的未提交變更時執行 `git` `merge`：雖然這是可行的，但在發生衝突時可能會讓您處於難以恢復的狀態。

選項

--commit
--no-commit: 執行合併並提交結果。此選項可用於覆蓋 --no-commit。

使用 --no-commit 時，執行合併並在建立合併提交之前停止，讓使用者有機會在提交前檢查並進一步調整合併結果。

請注意，快轉（fast-forward）更新不會建立合併提交，因此無法使用 --no-commit 停止此類合併。因此，如果您希望確保您的分支不會被合併命令更改或更新，請同時使用 --no-ff 與 --no-commit。
--edit
-e
--no-edit: 在成功執行機械式合併後提交前呼叫編輯器，以進一步編輯自動產生的合併訊息，讓使用者可以解釋並說明合併的理由。--no-edit 選項可用於接受自動產生的訊息（通常不建議這麼做）。如果您在命令列使用 -m 選項提供了草稿訊息，但仍想在編輯器中進行編輯，那麼 --edit（或 -e）選項仍然很有用。

舊版腳本可能依賴於不允許使用者編輯合併紀錄訊息的歷史行為。他們在執行 git merge 時會看到編輯器開啟。為了更容易將這類腳本調整為更新後的行為，可以在腳本開頭將環境變數 GIT_MERGE_AUTOEDIT 設為 no。
--cleanup=<mode>: 此選項決定在提交前如何清理合併訊息。詳細資訊請參閱 git-commit[1]。此外，若 <mode> 的值設為 scissors，在合併衝突的情況下，剪刀標記（scissors）將會被附加到 MERGE_MSG，之後再傳遞給提交機制。
--ff
--no-ff
--ff-only: 指定當被合併的歷史紀錄已經是當前歷史紀錄的後代時，該如何處理合併。--ff 是預設值，除非合併的是一個未儲存在 refs/tags/ 層級中自然位置的註釋（且可能已簽署）標籤，在這種情況下，預設會視為 --no-ff。

使用 --ff 時，盡可能以快轉方式解決合併（僅更新分支指標以符合被合併的分支；不建立合併提交）。當無法快轉時（當被合併的歷史紀錄不是當前歷史紀錄的後代時），則建立一個合併提交。

使用 --no-ff 時，無論何種情況都建立合併提交，即使該合併原本可以以快轉方式解決。

使用 --ff-only 時，盡可能以快轉方式解決合併。當無法快轉時，拒絕合併並以非零狀態碼退出。
-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign: 對產生的合併提交進行 GPG 簽署。<key-id> 引數是選填的，預設為提交者的身分；若指定了，必須緊貼在選項後，中間不能有空格。--no-gpg-sign 用於抵銷 commit.gpgSign 設定變數以及之前設定的 --gpg-sign。
--log[=<n>]
--no-log: 除了分支名稱外，還要在紀錄訊息中加入最多 <n> 個實際被合併提交的單行描述。另請參閱 git-fmt-merge-msg[1]。

使用 --no-log 時，不列出實際被合併提交的單行描述。
--signoff
--no-signoff: 在提交日誌訊息末尾由提交者新增一個 Signed-off-by 結尾。簽署的含義取決於您提交的專案。例如，它可以證明提交者有權在專案許可證下提交作品，或者同意某些貢獻者聲明，例如開發者來源證明 (DCO)。（有關 Linux 核心和 Git 專案使用的證明，請參閱 https://developercertificate.org。）請查閱您貢獻的專案的說明文件或領導層，以瞭解在該專案中如何使用簽署。

--no-signoff 選項可用於撤銷指令列中先前的 --signoff 選項。

Git 沒有（且將不會有）設定變數來預設啟用 --signoff 命令列選項；詳情請參閱 gitfaq[7] 中的 commit.signoff 條目。
--stat
-n
--no-stat: 在合併結束時顯示 diffstat。Diffstat 也受設定選項 merge.stat 控制。

使用 -n 或 --no-stat 時，不在合併結束時顯示 diffstat。
--compact-summary: 在合併結束時顯示精簡摘要（compact-summary）。
--squash
--no-squash: 產生的工作樹和索引狀態就像發生了真實合併一樣（除了合併資訊），但實際上並不進行提交、移動 HEAD，也不記錄 $GIT_DIR/MERGE_HEAD（這會導致下一個 git commit 命令建立合併提交）。這讓您可以將另一個分支（或八爪魚合併中的多個分支）的合併效果變成當前分支頂端的一個單一提交。

使用 --no-squash 時，執行合併並提交結果。此選項可用於覆蓋 --squash。

使用 --squash 時，不允許使用 --commit，否則會失敗。
--verify
--no-verify: 預設情況下，會執行預合併（pre-merge）和提交訊息（commit-msg）勾點（hooks）。當提供 --no-verify 時，這些勾點會被跳過。另請參閱 githooks[5]。
-s <strategy>
--strategy=<strategy>: 使用給定的合併策略；可以提供多次以指定嘗試的順序。如果沒有 -s 選項，則改為使用內建的策略列表（合併單個頭時為 ort，否則為 octopus）。
-X <option>
--strategy-option=<option>: 將特定於合併策略的選項傳遞給該合併策略。
--verify-signatures
--no-verify-signatures: 驗證被合併分支的頂端提交是否使用有效金鑰簽署，即具有有效 UID 的金鑰：在預設信任模型中，這意味著該簽署金鑰已被受信任的金鑰所簽署。如果分支頂端提交未以有效金鑰簽署，則合併將中止。
--summary
--no-summary: --stat 和 --no-stat 的同義詞；這些選項已棄用，將在未來版本移除。
-q
--quiet: 安靜地操作。隱含 --no-progress。
-v
--verbose: 顯示詳細資訊。
--progress
--no-progress: 明確開啟或關閉進度報告。如果未指定兩者，則當標準錯誤連線至終端時會顯示進度。請注意，並非所有合併策略都支援進度報告。
--autostash
--no-autostash: 在操作開始前自動建立一個臨時暫存（stash）項目，將其記錄在參照 MERGE_AUTOSTASH 中，並在操作結束後套用它。這意味著您可以在髒的工作樹上執行操作。然而，使用時請小心：合併成功後最終套用暫存時，可能會產生非瑣碎的衝突。
--allow-unrelated-histories: 預設情況下，git merge 命令拒絕合併沒有共同祖先的歷史紀錄。此選項可用於在合併兩個獨立發展的專案歷史時覆蓋此安全檢查。由於這種情況非常罕見，因此不存在（也不會增加）預設啟用此功能的設定變數。
-m <msg>: 設定用於合併提交的提交訊息（如果建立了合併提交）。

如果指定了 --log，被合併提交的簡短紀錄（shortlog）將會附加到指定的訊息中。

git fmt-merge-msg 命令可用於為自動化的 git merge 呼叫提供合適的預設訊息。自動產生的訊息可以包含分支描述。
--into-name <branch>: 準備預設的合併訊息時，假裝是要合併到 <branch> 分支，而不是實際執行合併的分支名稱。
-F <file>
--file=<file>: 讀取要用於合併提交的提交訊息（如果建立了合併提交）。

如果指定了 --log，被合併提交的簡短紀錄（shortlog）將會附加到指定的訊息中。
--rerere-autoupdate
--no-rerere-autoupdate: 在 rerere 機制重複使用已記錄的衝突解決方案來更新工作區中的檔案後，允許其同時更新索引。使用 --no-rerere-autoupdate 可以在使用單獨的 git-add[1] 將結果提交到索引之前，再次檢查 git-rerere[1] 的操作並捕捉潛在的錯誤合併。
--overwrite-ignore
--no-overwrite-ignore: 靜默地覆寫合併結果中被忽略的檔案。這是預設行為。使用 --no-overwrite-ignore 來中止。
--abort: 中止當前的衝突解決流程，並嘗試重構合併前的狀態。如果存在 autostash 項目，將其套用到工作樹。

如果合併開始時存在未提交的工作樹變更，git merge --abort 在某些情況下將無法重構這些變更。因此，建議在執行 git merge 之前始終提交或暫存您的變更。

當存在 MERGE_HEAD 時，git merge --abort 等同於 git reset --merge，除非同時存在 MERGE_AUTOSTASH。在後者情況下，git merge --abort 會將該暫存項目套用到工作樹，而 git reset --merge 則會將暫存的變更儲存到暫存列表中。
--quit: 遺忘當前正在進行的合併。保持索引和工作樹原樣。如果存在 MERGE_AUTOSTASH，則該暫存項目將被儲存到暫存列表中。
--continue: 當 git merge 因衝突而停止後，您可以透過執行 git merge --continue 來完成合併（請參閱下方「如何解決衝突」章節）。
<commit>...: 要合併到我們分支中的提交，通常是其他分支的頂端。指定多於一個提交將會建立一個擁有兩個以上父提交的合併（親切地稱為「八爪魚合併」）。

如果在命令列未給定提交，則合併當前分支設定要使用的上游遠端追蹤分支。另請參閱本手冊頁面的設定章節。

當指定 FETCH_HEAD（且無其他提交）時，上一次執行 git fetch 時在 .git/FETCH_HEAD 檔案中記錄用於合併的分支，將會被合併到當前分支。

合併前檢查

在套用外部變更之前，您應該先將自己的工作整理好並在本機提交，這樣如果發生衝突就不會被覆蓋。另請參閱 git-stash[1]。git pull 和 git merge 會在當前未提交的變更與 git pull/git merge 可能需要更新的檔案重疊時，停止執行而不做任何事情。

為了避免在合併提交中記錄不相關的變更，如果索引中有相對於 HEAD 提交的任何變更，git pull 和 git merge 也會中止。（根據所使用的合併策略，可能存在特殊的狹窄例外情況，但通常索引必須符合 HEAD。）

如果所有命名的提交都已經是 HEAD 的祖先，git merge 將會提前退出並顯示訊息「Already up to date.」。

快轉合併

通常當前分支頭是指定提交的祖先。這是最常見的情況，特別是當從 git pull 呼叫時：您正在追蹤一個上游儲存庫，您沒有提交任何本機變更，現在您想要更新到較新的上游版本。在這種情況下，不需要新的提交來儲存合併後的歷史；相反地，HEAD（連同索引）會直接更新以指向指定的提交，而不會建立額外的合併提交。

此行為可以透過 --no-ff 選項來抑制。

真實合併

除了快轉合併（見上文）外，要合併的分支必須透過一個同時以兩者作為父提交的合併提交繫結在一起。

一個調和了所有要合併分支變更的合併版本會被提交，並且您的 HEAD、索引和工作樹都會更新到該版本。工作樹中可以有修改，只要它們沒有重疊；更新將會保留它們。

當如何調和這些變更並不明顯時，會發生以下情況

HEAD 指標保持不變。
MERGE_HEAD 參照被設定為指向另一個分支的頂端。
乾淨合併的路徑會在索引檔案和您的工作樹中更新。
對於衝突的路徑，索引檔案會記錄最多三個版本：階段 1 儲存來自共同祖先的版本，階段 2 來自 HEAD，階段 3 來自 MERGE_HEAD（您可以使用 git ls-files -u 檢查這些階段）。工作樹檔案包含合併操作的結果；即帶有熟悉衝突標記 <<< === >>> 的三路合併結果。
會寫入一個名為 AUTO_MERGE 的參照，指向對應於當前工作樹內容的樹（包含文字衝突的衝突標記）。請注意，此參照僅在使用 ort 合併策略（預設值）時才會寫入。
不會做其他變更。特別是，您在開始合併前所擁有的本機修改將保持不變，且它們的索引條目也會保持原樣，即符合 HEAD。

如果您嘗試的合併導致了複雜的衝突並想要重新開始，您可以使用 git merge --abort 來復原。

合併標籤

當合併一個註釋（且可能已簽署）的標籤時，即使可以進行快轉合併，Git 也總是會建立一個合併提交，並且提交訊息範本會以標籤訊息準備。此外，如果該標籤已簽署，簽署檢查結果會作為註解報告在訊息範本中。另請參閱 git-tag[1]。

當您只想與導致該標籤提交的工作進行整合（例如與上游發佈點同步）時，您可能不想建立不必要的合併提交。

在這種情況下，您可以自己在將其傳遞給 git merge 之前「解開（unwrap）」標籤，或者在您自己沒有任何工作時傳遞 --ff-only，例如。

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

衝突呈現方式

在合併期間，工作樹檔案會更新以反映合併結果。在對共同祖先版本所做的變更中，不重疊的部分（即，您修改了檔案的某個區域，而另一方讓該區域保持完整，反之亦然）會直接原樣併入最終結果。然而，當雙方都對同一區域做了修改時，Git 無法隨意選擇其中一方，並透過保留雙方對該區域所做的工作，要求您來解決衝突。

預設情況下，Git 使用與 RCS 套件中的 "merge" 程式所使用的相同風格來呈現這種衝突區塊，如下所示

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

發生一對衝突變更的區域會標有 <<<<<<<、======= 和 >>>>>>> 標記。======= 之前的部份通常是您的一方，而之後的部份則是對方的一方。

預設格式不會顯示原始內容在衝突區域中的樣子。您無法判斷在您的一方刪除了多少行並替換為 Barbie 的評論。您唯一能判斷的是您的一方想說這很難，而您比較傾向去購物，而對方則想聲稱這很容易。

可以透過將 merge.conflictStyle 設定變數設為 diff3 或 zdiff3 來使用替代風格。在 diff3 風格中，上述衝突可能看起來像這樣

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

而在 zdiff3 風格中，可能看起來像這樣

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

除了 <<<<<<<、======= 和 >>>>>>> 標記外，它還使用了另一個 ||||||| 標記，其後跟隨著原始文字。您可以看出原始文字只是陳述了一個事實，而您的一方只是屈服於該陳述並放棄了，而對方則試圖保持更積極的態度。透過查看原始文字，您有時可以得出更好的解決方案。

如何解決衝突

看到衝突後，您可以做兩件事

決定不合併。您唯一需要做的清理工作是將索引檔案重設為 HEAD 提交以反轉第 2 步，並清理第 2 步和第 3 步所做的工作樹變更；git merge --abort 可用於此。
解決衝突。Git 會在工作樹中標記衝突。將檔案編輯成形，並使用 git add 將其加入索引。使用 git commit 或 git merge --continue 來完成交易。後者命令會在呼叫 git commit 之前檢查是否有（中斷的）合併正在進行。

您可以透過多種工具來解決衝突

使用合併工具。git mergetool 可以啟動圖形化合併工具，它會協助您完成合併。
查看差異。git diff 將顯示三路 diff，反白顯示來自 HEAD 和 MERGE_HEAD 版本的變更。git diff AUTO_MERGE 將顯示您迄今為止為了解決文字衝突所做的變更。
查看來自每個分支的差異。git log --merge -p <path> 將首先顯示 HEAD 版本，然後是 MERGE_HEAD 版本的 diff。
查看原始版本。git show :1:filename 顯示共同祖先，git show :2:filename 顯示 HEAD 版本，git show :3:filename 顯示 MERGE_HEAD 版本。

範例

將 fixes 和 enhancements 分支合併到當前分支，進行八爪魚合併
```
$ git merge fixes enhancements
```
使用 ours 合併策略將 obsolete 分支合併到當前分支
```
$ git merge -s ours obsolete
```
將 maint 分支合併到當前分支，但不要自動進行新提交
```
$ git merge --no-commit maint
```
這可以在您想要包含進一步的變更到合併中，或想要編寫自己的合併提交訊息時使用。

您應該避免濫用此選項將實質變更偷偷放入合併提交中。像調整發佈/版本名稱這樣的小修正則是可接受的。

合併策略

合併機制（git merge 和 git pull 命令）允許透過 -s 選項選擇後端 合併策略。某些策略還可以接受自己的選項，這些選項可以透過向 git merge 和/或 git pull 提供 -X<option> 參數來傳遞。

ort

這是拉取 (pull) 或合併單一分支時的預設合併策略。此策略僅能使用三方合併演算法解決兩個分支頭 (heads)。當有多個可用於三方合併的共同祖先時，它會建立一個共同祖先的合併樹，並將其用作三方合併的參考樹。根據在 Linux 2.6 核心開發歷史中的實際合併提交進行的測試，據報此方法產生的合併衝突較少，且不會導致錯誤合併。此外，此策略可以偵測並處理涉及重新命名的合併。它不使用偵測到的複製。此演算法的名稱是一個縮寫（「Ostensibly Recursive’s Twin」，意為表面上是遞迴策略的孿生兄弟），因為它是作為先前預設演算法 recursive 的替代方案而編寫的。

在路徑為子模組的情況下，如果合併的一側所使用的子模組提交是另一側所使用提交的後代，Git 會嘗試快速前進到該後代。否則，Git 會將此情況視為衝突，並建議使用一個同時是衝突提交之後代的子模組提交（如果存在）作為解決方案。

ort 策略可以接受以下選項：

ours

此選項強制偏向 our (我方) 版本以自動乾淨地解決衝突區塊。來自另一棵樹但不與我方衝突的更改會反映在合併結果中。對於二進位檔案，整個內容都取自我方。

這不應與 ours 合併策略混淆，後者甚至根本不查看另一棵樹的內容。它會丟棄另一棵樹所做的所有事情，宣稱 our 歷史已包含其中發生的所有事情。

theirs

這與 ours 相對；請注意，與 ours 不同，沒有 theirs 合併策略會與此合併選項混淆。

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

為了進行三方合併，將具有指定類型空白變更的行視為未更改。混合有其他更改的空白變更不會被忽略。另請參閱 git-diff[1] -b、-w、--ignore-space-at-eol 和 --ignore-cr-at-eol。

如果 their 版本僅在行中引入空白變更，則使用 our 版本；
如果 our 版本引入空白變更，但 their 版本包含實質性更改，則使用 their 版本；
否則，合併將以通常的方式進行。

renormalize

這會對需要三方合併的任何檔案的所有三個階段進行虛擬檢出和檢入。此選項旨在於合併具有不同 clean 過濾器或行尾標準化規則的分支時使用。詳情請參閱 gitattributes[5] 中的「合併具有不同檢入/檢出屬性的分支」。

no-renormalize

停用 renormalize 選項。這會覆蓋 merge.renormalize 設定變數。

find-renames[=<n>]

開啟重新命名偵測，並可選擇設定相似度閾值。這是預設行為。這會覆蓋 merge.renames 設定變數。另請參閱 git-diff[1] --find-renames。

rename-threshold=<n>

find-renames=<n> 的已棄用同義詞。

no-renames

關閉重新命名偵測。這會覆蓋 merge.renames 設定變數。另請參閱 git-diff[1] --no-renames。

histogram

diff-algorithm=histogram 的已棄用同義詞。

patience

diff-algorithm=patience 的已棄用同義詞。

diff-algorithm=(histogram|minimal|myers|patience)

合併時使用不同的差異演算法，這有助於避免因不重要的匹配行（如來自不同函式的大括號）而發生的錯誤合併。另請參閱 git-diff[1] --diff-algorithm。請注意，ort 預設為 diff-algorithm=histogram，而一般的差異比較目前預設為 diff.algorithm 設定。

subtree[=<path>]

此選項是 subtree 策略的一種進階形式，該策略會猜測合併時兩棵樹必須如何移動才能相互匹配。相反，指定的路徑會被加上前綴（或從開頭去除），以使兩棵樹的形狀匹配。

recursive

這現在是 ort 的同義詞。在 v2.49.0 之前，它是一個替代實作，但在 v2.50.0 中被重新導向為 ort。先前的遞迴 (recursive) 策略是從 Git v0.99.9k 到 v2.33.0 解決兩個分支頭的預設策略。

resolve

此策略僅能使用三方合併演算法解決兩個分支頭（即目前分支和您拉取的另一個分支）。它嘗試仔細偵測交叉合併的歧義。它不處理重新命名。

octopus

這可以解決兩個以上分支頭的情況，但拒絕執行需要手動解決的複雜合併。它主要用於將多個主題分支頭捆綁在一起。這是拉取或合併多個分支時的預設合併策略。

ours

這可以解決任意數量的分支頭，但合併後產生的樹始終是目前分支頭的樹，實際上忽略了來自所有其他分支的所有更改。它旨在用於取代舊的側支開發歷史。請注意，這與 ort 合併策略的 -Xours 選項不同。

subtree

這是一個修改後的 ort 策略。合併樹 A 和 B 時，如果 B 對應於 A 的子樹，則首先調整 B 以匹配 A 的樹結構，而不是在同一層級讀取樹。這種調整也會對共同祖先樹進行。

對於使用三方合併的策略（包括預設的 ort），如果在兩個分支上都做了更改，但後來在其中一個分支上還原了該更改，則合併結果中將存在該更改；有些人覺得這種行為很令人困惑。這是因為執行合併時只考慮分支頭和合併基底，而不考慮單個提交。因此，合併演算法將還原的更改視為完全沒有更改，並代之以更改後的版本。

組態設定 (CONFIGURATION)

branch.<name>.mergeOptions: 設定合併到分支 <name> 的預設選項。語法和支援的選項與 git merge 相同，但目前不支援包含空白字元的選項值。

本節此行以上的所有內容均未包含在 git-config[1] 說明文件中。接下來的內容與該處內容相同：

merge.conflictStyle

指定合併時衝突區塊寫入工作樹檔案的樣式。預設值為 "merge"，顯示一個 <<<<<<< 衝突標記、一方所做的變更、一個 ======= 標記、另一方所做的變更，然後是一個 >>>>>>> 標記。另一種風格 "diff3"，在 ======= 標記之前增加一個 ||||||| 標記和原始文字。"merge" 風格傾向於產生比 diff3 更小的衝突區域，這既是因為排除了原始文字，也是因為當兩側的一組行相符時，它們會直接從衝突區域中移除。另一種替代風格 "zdiff3" 與 diff3 類似，但在衝突區域的開始或結尾附近出現相符行時，會從衝突區域中移除兩側的相符行。

merge.defaultToUpstream

如果呼叫 merge 時沒有任何提交引數，則使用在遠端追蹤分支中觀察到的最後值，合併為當前分支設定的上游分支。會查閱 branch.<current branch>.merge 的值，這些值指定了由 branch.<current-branch>.remote 指定的遠端上的分支，然後透過 remote.<remote>.fetch 映射到它們對應的遠端追蹤分支，並合併這些追蹤分支的頂端。預設為 true。

merge.ff

預設情況下，Git 在合併一個作為當前提交後代的提交時，不會建立額外的合併提交。相反地，當前分支的頂端會進行快轉。當設為 false 時，此變數告訴 Git 在這種情況下建立額外的合併提交（等同於在命令列給定 --no-ff 選項）。當設為 only 時，僅允許此類快轉合併（等同於在命令列給定 --ff-only 選項）。

merge.verifySignatures

如果為 true，這等同於命令列選項 --verify-signatures。詳細資訊請參閱 git-merge[1]。

merge.branchdesc

除了分支名稱外，還要在日誌訊息中加入與其相關聯的分支描述文字。預設為 false。

merge.log

除了分支名稱外，還要在日誌訊息中加入最多指定數量的、來自實際被合併提交的一行說明。預設為 false，而 true 是 20 的同義詞。

merge.suppressDest

透過向此多值設定變數新增與整合分支名稱匹配的 glob，為合併到這些整合分支而計算的預設合併訊息將在其標題中省略 "into <分支名稱>"。

值為空的元素可用於清除從先前設定條目累積的 glob 清單。未定義 merge.suppressDest 變數時，為了向後相容，會使用預設值 master。

merge.renameLimit

合併期間在重新命名檢測的詳盡部分中要考慮的檔案數量。若未指定，預設為 diff.renameLimit 的值。如果既未指定 merge.renameLimit 也未指定 diff.renameLimit，則目前預設為 7000。如果關閉了重新命名檢測，此設定無效。

merge.renames

Git 是否偵測重新命名。若設為 false，則停用重新命名偵測。若設為 true，則啟用基本重新命名偵測。預設為 diff.renames 的值。

merge.directoryRenames

Git 是否偵測目錄重新命名，影響歷史紀錄一側新增到目錄的檔案，在歷史紀錄另一側該目錄被重新命名時，在合併時會發生什麼事。可能的數值為

false: 停用目錄重新命名偵測，這意味著此類新增的檔案將留在舊目錄中。
true: 啟用目錄重新命名偵測，這意味著此類新增的檔案將被移動到新目錄中。
conflict: 此類路徑將會報告衝突。

如果 merge.renames 為 false，則 merge.directoryRenames 會被忽略並視為 false。預設為 conflict。

merge.renormalize

告訴 Git 儲存庫中檔案的規範表示法隨著時間發生了變化（例如，較早的提交記錄文字檔案使用 CRLF 行尾，但最近的提交使用 LF 行尾）。在此類儲存庫中，對於每個需要三路內容合併的檔案，Git 可以在執行合併前將提交中記錄的資料轉換為規範形式，以減少不必要的衝突。如需更多資訊，請參閱 gitattributes[5] 中的「合併具有不同簽入/簽出屬性的分支」一節。

merge.stat

在合併結束時，在 ORIG_HEAD 和合併結果之間列印什麼（如果有的話）。可能的數值為

false: 什麼都不顯示。
true: 顯示 git diff --diffstat --summary ORIG_HEAD。
compact: 顯示 git diff --compact-summary ORIG_HEAD。

但任何無法辨識的值（例如，未來版本的 Git 所增加的值）都會被視為 true，而不是觸發錯誤。預設為 true。

merge.autoStash

當設為 true 時，在操作開始前自動建立一個臨時暫存項目，並在操作結束後套用它。這意味著您可以在髒的工作樹上執行 merge。然而，使用時請小心：合併成功後最終套用暫存時，可能會產生非瑣碎的衝突。此選項可以被 git-merge[1] 的 --no-autostash 和 --autostash 選項覆蓋。預設為 false。

merge.tool

控制 git-mergetool[1] 使用哪個合併工具。下方的列表顯示了有效的內建值。任何其他值都會被視為自訂合併工具，並要求定義對應的 mergetool.<tool>.cmd 變數。

merge.guitool

控制在指定了 -g/--gui 旗標時，git-mergetool[1] 使用哪個合併工具。下方的列表顯示了有效的內建值。任何其他值都會被視為自訂合併工具，並要求定義對應的 mergetool.<guitool>.cmd 變數。

araxis
bc
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
examdiff
guiffy
gvimdiff
kdiff3
meld
nvimdiff
opendiff
p4merge
smerge
tkdiff
tortoisemerge
vimdiff
vscode
winmerge
xxdiff

merge.verbosity

控制遞迴合併策略顯示的輸出量。層級 0 除了偵測到衝突時的最終錯誤訊息外，什麼都不輸出。層級 1 僅輸出衝突，層級 2 輸出衝突和檔案變更。層級 5 及以上會輸出偵錯資訊。預設為層級 2。可以透過 GIT_MERGE_VERBOSITY 環境變數覆蓋。

merge.<driver>.name

為自訂低階合併驅動程式定義人類可讀的名稱。詳細資訊請參閱 gitattributes[5]。

merge.<driver>.driver

定義實作自訂低階合併驅動程式的命令。詳細資訊請參閱 gitattributes[5]。

merge.<driver>.recursive

命名在執行共同祖先之間的內部合併時要使用的低階合併驅動程式。詳細資訊請參閱 gitattributes[5]。

參見

git-fmt-merge-msg[1], git-pull[1], gitattributes[5], git-reset[1], git-diff[1], git-ls-files[1], git-add[1], git-rm[1], git-mergetool[1]

git[1] 套件的一部分

設定與組態

取得與建立專案

基本快照

分支與合併

分享與更新專案

檢查與比較

修補

除錯

電子郵件

外部系統

伺服器管理

指南

管理

底層命令 (Plumbing Commands)

名稱

概要

描述

選項