Git

git-merge 最後更新於 2.47.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)

說明

將指定 commit 的變更（從其歷史與目前分支分歧的時間點開始）併入目前分支。此命令由 git pull 用來合併來自另一個儲存庫的變更，並且可以手動用來將變更從一個分支合併到另一個分支。

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

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

然後 git merge topic 會將在 topic 分支上所做的變更，從它與 master 分歧的時間點 (亦即 E) 開始，直到其目前的 commit (C) ，重播到 master 之上，並將結果記錄在新的 commit 中，同時記錄兩個父 commit 的名稱，以及來自使用者描述變更的記錄訊息。在操作之前，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 執行合併，並在建立合併 commit 之前停止，以便使用者有機會在提交之前檢查並進一步調整合併結果。

請注意，快速轉送更新不會建立合併 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，然後再傳遞給 commit 機制。
--ff
--no-ff
--ff-only: 指定當合併的歷史記錄已經是目前歷史記錄的後代時，如何處理合併。除非合併未在其 refs/tags/ 階層中的自然位置中儲存的已註解（且可能已簽署）的標籤，否則 --ff 為預設值，在這種情況下會假設為 --no-ff。

使用 --ff 時，如果可能，將合併解析為快速轉送（僅更新分支指標以符合合併的分支；不要建立合併 commit）。如果不可能（當合併的歷史記錄不是目前歷史記錄的後代時），則建立合併 commit。

使用 --no-ff 時，在所有情況下都建立合併 commit，即使在合併可以改為解析為快速轉送時也是如此。

使用 --ff-only 時，如果可能，將合併解析為快速轉送。如果不可能，則拒絕合併並以非零狀態退出。
-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign: 以 GPG 簽署產生的合併 commit。keyid 引數是選用的，預設為 committer 身分；如果指定，則必須將其貼在選項上，且不含空格。--no-gpg-sign 可用於反駁 commit.gpgSign 設定變數和先前的 --gpg-sign。
--log[=<n>]
--no-log: 除了分支名稱之外，還使用最多 <n> 個實際合併 commit 的單行描述來填入記錄訊息。另請參閱 git-fmt-merge-msg[1]。

使用 --no-log 不會列出來自實際合併 commit 的單行描述。
--signoff
--no-signoff: 在 commit 記錄訊息的結尾，新增由 committer 提供的 Signed-off-by 尾碼。簽署的意義取決於您要提交的專案。例如，它可能會證明 committer 有權根據專案的授權提交作品，或同意某些貢獻者聲明，例如開發人員原始憑證。(請參閱 https://developercertificate.org，以取得 Linux 核心和 Git 專案所使用的憑證。)請參閱您要貢獻的專案的文件或領導階層，以瞭解如何在該專案中使用簽署。

--no-signoff 選項可用於反駁命令列中較早的 --signoff 選項。
--stat
-n
--no-stat: 在合併結束時顯示 diffstat。diffstat 也由組態選項 merge.stat 控制。

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

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

使用 --squash 時，不允許使用 --commit，且會失敗。
--[no-]verify: 預設情況下，會執行 pre-merge 和 commit-msg hook。如果給定 --no-verify，則會略過這些 hook。另請參閱 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: 在操作開始前自動建立一個臨時的儲藏條目，將其記錄在 ref 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: 中止當前的衝突解決過程，並嘗試重建合併前的狀態。如果存在 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 將會提前退出並顯示訊息「已經是最新的」。

快轉合併

通常，目前分支頭是已命名提交的祖先。這是最常見的情況，尤其是在從 git pull 呼叫時：您正在追蹤上游儲存庫，您沒有提交任何本地變更，現在您想要更新到較新的上游修訂版本。在這種情況下，不需要新的提交來儲存組合的歷史記錄；相反，HEAD（以及索引）會更新為指向已命名的提交，而無需建立額外的合併提交。

可以使用 --no-ff 選項來抑制此行為。

真正的合併

除了快轉合併（請參閱上文）之外，要合併的分支必須透過將它們都作為父提交的合併提交連結在一起。

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

當不清楚如何協調變更時，會發生以下情況

HEAD 指標保持不變。
MERGE_HEAD ref 會設定為指向其他分支頭。
合併乾淨的路徑會在索引檔案和您的工作樹中更新。
對於衝突的路徑，索引檔案會記錄最多三個版本：階段 1 儲存來自共同祖先的版本，階段 2 儲存來自 HEAD 的版本，階段 3 儲存來自 MERGE_HEAD 的版本（您可以使用 git ls-files -u 檢查階段）。工作樹檔案包含合併操作的結果；也就是說，具有熟悉衝突標記 <<< === >>> 的 3 向合併結果。
一個名為 AUTO_MERGE 的 ref 會被寫入，指向與工作樹目前內容對應的樹（包括文字衝突的衝突標記）。請注意，只有在使用 ort 合併策略（預設）時才會寫入此 ref。
不會進行其他變更。特別是，您在開始合併之前擁有的本地修改將保持不變，並且它們的索引條目也會保持原樣，也就是說，與 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 commit 以反轉 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
```
使用 ours 合併策略將 obsolete 分支合併到目前分支
```
$ git merge -s ours obsolete
```
將 maint 分支合併到目前分支，但不要自動建立新的 commit
```
$ git merge --no-commit maint
```
當你想在合併中包含進一步的變更，或想撰寫自己的合併 commit 訊息時，可以使用此方法。

你不應該濫用此選項，在合併 commit 中偷偷塞入大量變更。像是更新發布/版本名稱等小修正尚可接受。

合併策略

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

ort

這是提取或合併一個分支時的預設合併策略。此策略只能使用三向合併演算法解決兩個頭。當有多個可以作為三向合併的共同祖先時，它會建立共同祖先的合併樹，並將其用作三向合併的參考樹。據報告，通過對取自 Linux 2.6 核心開發歷史的實際合併 commit 進行的測試，此方法可以減少合併衝突，而不會導致合併錯誤。此外，此策略可以偵測並處理涉及重新命名的合併。它不使用偵測到的副本。此演算法的名稱是一個縮寫（「表面上是遞迴的雙胞胎」），源自於它被寫成先前預設演算法 recursive 的替代品。

_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> 的已棄用同義詞。

subtree[=<path>]

此選項是 _subtree_ 策略的更進階形式，其中該策略會猜測當合併時必須如何移動兩個樹以相互匹配。相反地，指定的路徑會加上前綴（或從開頭剝離），使兩個樹的形狀匹配。

recursive

此策略只能使用三向合併演算法解決兩個頭。當有多個可以作為三向合併的共同祖先時，它會建立共同祖先的合併樹，並將其用作三向合併的參考樹。據報告，通過對取自 Linux 2.6 核心開發歷史的實際合併 commit 進行的測試，此方法可以減少合併衝突，而不會導致合併錯誤。此外，它可以偵測並處理涉及重新命名的合併。它不使用偵測到的副本。這是從 Git v0.99.9k 到 v2.33.0 解決兩個頭的預設策略。

_recursive_ 策略採用與 _ort_ 相同的選項。但是，_ort_ 會忽略三個額外選項（上面未記載），這些選項可能對 _recursive_ 策略有用

patience: diff-algorithm=patience 的已棄用同義詞。
diff-algorithm=[patience|minimal|histogram|myers]: 在合併時使用不同的差異演算法，這可以幫助避免因不重要的匹配行（例如來自不同函數的括號）而發生的錯誤合併。另請參閱 git-diff[1] --diff-algorithm。請注意，ort 專門使用 diff-algorithm=histogram，而 recursive 預設為 diff.algorithm 組態設定。
no-renames: 關閉重新命名偵測。這會覆寫 merge.renames 組態變數。另請參閱 git-diff[1] --no-renames。

resolve

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

octopus

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

ours

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

subtree

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

對於使用三向合併的策略（包括預設的 _ort_），如果在兩個分支上都進行了變更，但稍後在其中一個分支上還原了該變更，則該變更將會存在於合併結果中；有些人覺得這種行為令人困惑。之所以發生這種情況，是因為執行合併時僅考慮頭和合併基準，而不考慮個別的 commit。因此，合併演算法會將還原的變更視為根本沒有變更，並改用變更的版本。

組態

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

預設情況下，當合併的 commit 是目前 commit 的後代時，Git 不會建立額外的合併 commit。相反地，目前分支的頂端會快速推進（fast-forwarded）。當設定為 false 時，此變數會告知 Git 在這種情況下建立額外的合併 commit（相當於從命令列提供 --no-ff 選項）。當設定為 only 時，只允許這種快速推進合併（相當於從命令列提供 --ff-only 選項）。

merge.verifySignatures

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

merge.branchdesc

除了分支名稱之外，還會在記錄訊息中填入與它們相關聯的分支描述文字。預設為 false。

merge.log

除了分支名稱之外，還會在記錄訊息中填入最多指定數量的實際合併 commit 的單行描述。預設為 false，而 true 是 20 的同義詞。

merge.suppressDest

透過將符合整合分支名稱的 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 是否偵測目錄重新命名，這會影響在合併時，當目錄在歷史記錄的一側重新命名時，添加到歷史記錄另一側目錄的新檔案會發生什麼情況。如果 merge.directoryRenames 設定為 "false"，則會停用目錄重新命名偵測，這表示這些新檔案會留在舊目錄中。如果設定為 "true"，則會啟用目錄重新命名偵測，這表示這些新檔案會移動到新目錄中。如果設定為 "conflict"，則會針對這些路徑報告衝突。如果 merge.renames 為 false，則 merge.directoryRenames 會被忽略並視為 false。預設為 "conflict"。

merge.renormalize

告知 Git 儲存庫中檔案的標準表示法已隨時間變更（例如，較早的 commit 會記錄具有 CRLF 行尾的文字檔，但最近的 commit 會使用 LF 行尾）。在這樣的儲存庫中，Git 可以在執行合併之前將 commit 中記錄的資料轉換為標準形式，以減少不必要的衝突。如需更多資訊，請參閱 gitattributes[5] 中的「合併具有不同簽入/簽出屬性的分支」章節。

merge.stat

是否在合併結束時印出 ORIG_HEAD 和合併結果之間的 diffstat。預設為 True。

merge.autoStash

當設定為 true 時，會在操作開始前自動建立臨時 stash 項目，並在操作結束後套用它。這表示您可以在有髒工作樹的情況下執行合併。但是，請謹慎使用：在成功合併後最終套用 stash 可能會導致非微不足道的衝突。此選項可以被 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] 套件的一部分

設定與配置

取得與建立專案

基本快照

分支與合併

分享與更新專案

檢查與比較

修補

除錯

電子郵件

外部系統

伺服器管理

指南

管理

底層命令

名稱

概要

說明

選項