Git

git-merge 上次更新於 2.50.0

名稱

git-merge - 合併兩個或多個開發歷史

概要

git merge [-n] [--stat] [--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) 之間所做的更改，並將其記錄在 master 之上的一個新提交中，同時包含兩個父提交的名稱和使用者描述更改的日誌訊息。在操作之前，ORIG_HEAD 被設定為當前分支的尖端 (C)。

	  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 執行合併，並在建立合併提交之前停止，以便使用者有機會在提交之前檢查和進一步調整合並結果。

請注意，快進式更新不會建立合併提交，因此無法使用 --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 值，則在發生合併衝突時，剪刀將附加到 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 尾部資訊。簽名的含義取決於您提交的專案。例如，它可能證明提交者有權根據專案的許可證提交作品，或者同意某些貢獻者宣告，例如開發者原產地證書。（有關 Linux 核心和 Git 專案使用的證書，請參閱 https://developercertificate.org。）請查閱您所貢獻專案的文件或領導層，以瞭解該專案中籤名的使用方式。

可以使用 --no-signoff 選項來抵消命令列中較早的 --signoff 選項。
--stat
-n
--no-stat: 在合併結束時顯示 diffstat。diffstat 也受配置選項 merge.stat 控制。

使用 -n 或 --no-stat 不在合併結束時顯示 diffstat。
--squash
--no-squash: 生成工作樹和索引狀態，就像實際合併發生一樣（合併資訊除外），但實際上不進行提交，不移動 HEAD，也不記錄 $GIT_DIR/MERGE_HEAD（以使下一個 git commit 命令建立合併提交）。這允許您在當前分支之上建立一個單獨的提交，其效果與合併另一個分支（或在章魚合併的情況下更多）相同。

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

使用 --squash 時，不允許使用 --commit，並且會失敗。
--[no-]verify: 預設情況下，pre-merge 和 commit-msg 鉤子會被執行。當給出 --no-verify 時，這些鉤子會被繞過。另請參閱 githooks[5]。
-s <strategy>
--strategy=<strategy>: 使用給定的合併策略；可以多次提供以指定它們的嘗試順序。如果沒有 -s 選項，則使用內建策略列表（合併單個頭時使用 ort，否則使用 octopus）。
-X <option>
--strategy-option=<option>: 將合併策略特定選項傳遞給合併策略。
--verify-signatures
--no-verify-signatures: 驗證被合併的側分支的尖端提交是否用有效金鑰簽名，即在預設信任模型中，這意味著簽名金鑰已由受信任金鑰簽名。如果側分支的尖端提交未用有效金鑰簽名，則合併中止。
--summary
--no-summary: 等同於 --stat 和 --no-stat；這些已被棄用，將來會移除。
-q
--quiet: 安靜操作。隱含 --no-progress。
-v
--verbose: 顯示詳細資訊。
--progress
--no-progress: 顯式開啟/關閉進度顯示。如果兩者都未指定，則當標準錯誤連線到終端時顯示進度。請注意，並非所有合併策略都可能支援進度報告。
--autostash
--no-autostash: 在操作開始前自動建立一個臨時暫存條目，將其記錄在引用 MERGE_AUTOSTASH 中，並在操作結束後應用。這意味著您可以在髒工作樹上執行操作。但是，請謹慎使用：成功合併後的最終暫存應用可能會導致非平凡的衝突。
--allow-unrelated-histories: 預設情況下，git merge 命令拒絕合併沒有共同祖先的歷史。此選項可用於在合併兩個獨立開始的專案歷史時覆蓋此安全限制。由於這種情況非常罕見，因此不存在或不會新增預設啟用此功能的配置變數。
-m <msg>: 設定合併提交（如果建立）要使用的提交訊息。

如果指定了 --log，則合併的提交的簡短日誌將附加到指定的訊息中。

命令 git fmt-merge-msg 可用於為自動 git merge 呼叫提供一個良好的預設值。自動生成的訊息可以包含分支描述。
--into-name <branch>: 準備預設合併訊息，就像合併到分支 <branch> 一樣，而不是合併到的實際分支的名稱。
-F <file>
--file=<file>: 讀取合併提交（如果建立）要使用的提交訊息。

如果指定了 --log，則合併的提交的簡短日誌將附加到指定的訊息中。
--rerere-autoupdate
--no-rerere-autoupdate: 在 rerere 機制重用當前衝突上的已記錄解決方案來更新工作樹中的檔案之後，允許它也用解決方案結果更新索引。--no-rerere-autoupdate 是一個很好的方式來仔細檢查 rerere 的作用，並在使用單獨的 git add 將結果提交到索引之前捕獲潛在的錯誤合併。
--overwrite-ignore
--no-overwrite-ignore: 靜默覆蓋合併結果中的忽略檔案。這是預設行為。使用 --no-overwrite-ignore 來中止。
--abort: 中止當前的衝突解決過程，並嘗試重建合併前的狀態。如果存在自動暫存條目，則將其應用於工作樹。

如果合併開始時存在未提交的工作樹更改，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_HEAD 檔案中由上一次 git fetch 呼叫為合併而記錄的分支將被合併到當前分支。

合併前檢查

在應用外部更改之前，您應該確保自己的工作狀態良好並已在本地提交，這樣在發生衝突時就不會被覆蓋。另請參閱 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 之前自行“解包”標籤，或者在您沒有任何自己的工作時傳遞 --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.

發生一對沖突更改的區域用標記 <<<<<<<、======= 和 >>>>>>> 標記。 ======= 之前的部分通常是您這邊的內容，之後的部分通常是對方這邊的內容。

預設格式不顯示原始衝突區域說了什麼。您無法判斷您的版本中刪除了多少行並替換為芭比的評論。您唯一能知道的是，您這邊想說這很困難，您更喜歡去購物，而另一邊想聲稱這很容易。

可以透過將 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 將顯示一個三方差異，突出顯示 HEAD 和 MERGE_HEAD 版本的更改。git diff AUTO_MERGE 將顯示您目前為解決文字衝突所做的更改。
檢視每個分支的差異。git log --merge -p <path> 將首先顯示 HEAD 版本的差異，然後是 MERGE_HEAD 版本的差異。
檢視原始檔案。git show :1:filename 顯示共同祖先，git show :2:filename 顯示 HEAD 版本，git show :3:filename 顯示 MERGE_HEAD 版本。

示例

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

您應避免濫用此選項以偷偷地將大量更改引入合併提交。諸如增加發布/版本名稱等小型修復是可以接受的。

合併策略

合併機制（git merge 和 git pull 命令）允許使用 -s 選項選擇後端 合併策略。一些策略也可以接受它們自己的選項，可以透過將 -X<option> 引數傳遞給 git merge 和/或 git pull 來傳遞。

ort

這是拉取或合併一個分支時的預設合併策略。此策略只能使用三方合併演算法解決兩個頭。當存在多個可用於三方合併的共同祖先時，它會建立共同祖先的合併樹，並將其用作三方合併的參考樹。根據對 Linux 2.6 核心開發歷史中實際合併提交的測試，據報道這會導致更少的合併衝突，而不會導致錯誤合併。此外，此策略可以檢測和處理涉及重新命名的合併。它不使用檢測到的複製。此演算法的名稱是首字母縮略詞（“Ostensibly Recursive’s Twin”，表面上是遞迴的雙胞胎），源於它是作為先前預設演算法 recursive 的替代品而編寫的事實。

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

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

ours

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

這不應與 ours 合併策略混淆，後者根本不檢視其他樹包含什麼。它丟棄了其他樹所做的所有事情，宣告 我們的 歷史包含了其中發生的所有事情。

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。

如果*他們的*版本只引入了行的空白符更改，則使用*我們的*版本；
如果*我們的*版本引入了空白符更改但*他們的*版本包含了實質性更改，則使用*他們的*版本；
否則，合併按常規方式進行。

renormalize

這會對需要三方合併的任何檔案的所有三個階段執行虛擬檢出和檢入。此選項旨在用於合併具有不同清理過濾器或行尾規範化規則的分支。有關詳細資訊，請參閱 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)

合併時使用不同的 diff 演算法，這有助於避免因不重要的匹配行（例如來自不同函式的括號）而導致的錯誤合併。另請參閱 git-diff[1] --diff-algorithm。請注意，ort 預設為 diff-algorithm=histogram，而常規 diff 當前預設為 diff.algorithm 配置設定。

subtree[=<path>]

此選項是 subtree 策略的一種更高階形式，其中策略會猜測在合併時如何移動兩棵樹以使其相互匹配。相反，指定的路徑被新增字首（或從開頭剝離），以使兩棵樹的形狀匹配。

recursive

這現在是 ort 的同義詞。它在 v2.49.0 之前是一個替代實現，但在 v2.50.0 中被重定向為表示 ort。先前的遞迴策略是 Git v0.99.9k 到 v2.33.0 之間解決兩個頭部的預設策略。

resolve

這隻能使用三向合併演算法解決兩個頭部（即當前分支和你拉取的另一個分支）。它嘗試仔細檢測交叉合併歧義。它不處理重新命名。

octopus

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

ours

這解決了任意數量的頭部，但合併的結果樹始終是當前分支頭部的樹，有效地忽略了所有其他分支的所有更改。它旨在用於取代側分支的舊開發歷史。請注意，這與 ort 合併策略的 -Xours 選項不同。

subtree

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

對於使用三方合併的策略（包括預設的 ort），如果某個更改在兩個分支上都進行了，但後來在一個分支上被撤銷，則該更改將出現在合併結果中；有些人覺得這種行為令人困惑。這種情況發生是因為在執行合併時只考慮了頭和合並基礎，而不是單獨的提交。因此，合併演算法將撤銷的更改視為沒有更改，並替換為已更改的版本。

配置

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

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

merge.conflictStyle

指定合併時衝突塊寫入工作樹檔案的方式。預設是“merge”，它顯示一個 <<<<<<< 衝突標記，一方所做的更改，一個 ======= 標記，另一方所做的更改，然後是一個 >>>>>>> 標記。另一種樣式，“diff3”，在 ======= 標記之前新增一個 ||||||| 標記和原始文字。“merge”樣式傾向於產生比 diff3 更小的衝突區域，這既因為排除了原始文字，也因為當兩邊的一部分行匹配時，它們只是被從衝突區域中拉出。另一種替代樣式，“zdiff3”，類似於 diff3，但當匹配行出現在衝突區域的開頭或結尾附近時，它會從衝突區域中移除兩邊匹配的行。

merge.defaultToUpstream

如果呼叫 merge 時沒有 commit 引數，則使用當前分支配置的上游分支，透過其遠端跟蹤分支中儲存的最後觀察值進行合併。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

透過將匹配整合（integration）分支名稱的 glob 新增到此多值配置變數中，計算出的合併到這些整合分支的預設合併訊息將省略標題中的“into <branch-name>”。

空值元素可用於清除從先前配置條目累積的 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 和合並結果之間的 diffstat。預設為 true。

merge.autoStash

當設定為 true 時，在操作開始前自動建立一個臨時暫存條目，並在操作結束後應用。這意味著您可以在髒工作樹上執行合併。但是，請謹慎使用：成功合併後的最終暫存應用可能會導致非平凡的衝突。此選項可以被 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] 套件的一部分

設定和配置

獲取和建立專案

基本快照

分支與合併

共享和更新專案

檢查和比較

打補丁

除錯

電子郵件

外部系統

伺服器管理

指南

管理

底層命令

名稱

概要

描述

選項