# git-merge > 原文： [https://git-scm.com/docs/git-merge](https://git-scm.com/docs/git-merge) ## 名稱 git-merge - 將兩個或多個開發歷史記錄連接在一起 ## 概要 ``` git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>…?] git merge --abort git merge --continue ``` ## 描述 將來自命名提交的更改（自其歷史記錄與當前分支分開時）合并到當前分支中。 _git pull_ 使用此命令來合并來自另一個存儲庫的更改，并且可以手動使用此命令將更改從一個分支合并到另一個分支。 假設存在以下歷史記錄，當前分支為“`master`”： ``` A---B---C topic / D---E---F---G master ``` 然后“`git merge topic`”將重放`topic`分支上的更改，因為它從`master`（即`E`）轉移到`master`之上的當前提交（`C`），并記錄導致新提交以及兩個父提交的名稱和來自用戶的描述更改的日志消息。 ``` A---B---C topic / \ D---E---F---G---H master ``` 第二種語法（“`git merge --abort`”）只能在合并導致沖突后運行。 _git merge --abort_ 將中止合并過程并嘗試重建合并前狀態。但是，如果在合并開始時有未提交的更改（特別是如果在合并開始后進一步修改了這些更改）， _git merge --abort_ 在某些情況下將無法重建原始（之前） - 改變。因此： **警告**：不鼓勵運行 _git merge_ 并進行非平凡的未提交更改：盡管可能，但如果發生沖突，可能會使您處于難以退出的狀態。 第三種語法（“`git merge --continue`”）只能在合并導致沖突后運行。 ## OPTIONS ``` --commit ``` ``` --no-commit ``` 執行合并并提交結果。此選項可用于覆蓋--no-commit。 使用--no-commit執行合并但假裝合并失敗并且不自動提交，以便讓用戶有機會在提交之前檢查并進一步調整合并結果。 ``` --edit ``` ``` -e ``` ``` --no-edit ``` 在提交成功的機械合并之前調用編輯器以進一步編輯自動生成的合并消息，以便用戶可以解釋并證明合并。 `--no-edit`選項可用于接受自動生成的消息（通常不鼓勵這樣做）。如果從命令行給出帶有`-m`選項的草稿消息并想在編輯器中編輯它，`--edit`（或`-e`）選項仍然有用。 較舊的腳本可能取決于不允許用戶編輯合并日志消息的歷史行為。他們將在運行`git merge`時看到編輯器打開。為了便于將此類腳本調整為更新的行為，可以在環境變量`GIT_MERGE_AUTOEDIT`的開頭設置為`no`。 ``` --ff ``` 當合并解析為快進時，僅更新分支指針，而不創建合并提交。這是默認行為。 ``` --no-ff ``` 即使合并解析為快進，也要創建合并提交。這是在 _refs / tags /_ 層次結構中合并未存儲在其自然位置的帶注釋（且可能已簽名）的標記時的默認行為。 ``` --ff-only ``` 拒絕以非零狀態合并和退出，除非當前`HEAD`已經是最新的，或者合并可以解析為快進。 ``` -S[<keyid>] ``` ``` --gpg-sign[=<keyid>] ``` GPG簽署生成的合并提交。 `keyid`參數是可選的，默認為提交者標識;如果指定，它必須粘在沒有空格的選項上。 ``` --log[=<n>] ``` ``` --no-log ``` 除了分支名稱之外，還使用最多&lt; n&gt;的單行描述填充日志消息。正在合并的實際提交。另見 [git-fmt-merge-msg [1]](https://git-scm.com/docs/git-fmt-merge-msg) 。 使用--no-log不會列出正在合并的實際提交中的單行描述。 ``` --signoff ``` ``` --no-signoff ``` 在提交日志消息的末尾由提交者添加逐行簽名。簽收的含義取決于項目，但它通常證明提交者有權在同一許可下提交此作品并同意開發者原產地證書（參見 [http://developercertificate.org/](http://developercertificate.org/) ] 欲獲得更多信息）。 使用--no-signoff時不要添加Sign-off-by行。 ``` --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。 ``` -s <strategy> ``` ``` --strategy=<strategy> ``` 使用給定的合并策略;可以多次提供，以按照應該嘗試的順序指定它們。如果沒有`-s`選項，則使用內置的策略列表（合并單個頭時 _git merge-recursive_ ，否則使用 _git merge-octopus_ ）。 ``` -X <option> ``` ``` --strategy-option=<option> ``` 將合并策略特定選項傳遞給合并策略。 ``` --verify-signatures ``` ``` --no-verify-signatures ``` 驗證正在合并的側分支的提示提交是否使用有效密鑰簽名，即具有有效uid的密鑰：在默認信任模型中，這意味著簽名密鑰已由可信密鑰簽名。如果側分支的提示提交未使用有效密鑰簽名，則合并將中止。 ``` --summary ``` ``` --no-summary ``` 同義詞--stat和--no-stat;這些已被棄用，將來會被刪除。 ``` -q ``` ``` --quiet ``` 安靜地操作。意味著 - 沒有進步。 ``` -v ``` ``` --verbose ``` 要冗長。 ``` --progress ``` ``` --no-progress ``` 明確打開/關閉進度。如果兩者都未指定，則在標準錯誤連接到終端時顯示進度。請注意，并非所有合并策略都可以支持進度報告。 ``` --allow-unrelated-histories ``` 默認情況下，`git merge`命令拒絕合并不共享共同祖先的歷史記錄。在合并獨立開始生命的兩個項目的歷史時，此選項可用于覆蓋此安全性。由于這是一種非常罕見的情況，因此默認情況下不會啟用任何配置變量來啟用它，也不會添加。 ``` -m <msg> ``` 設置要用于合并提交的提交消息（如果創建了一個）。 如果指定了`--log`，則正在合并的提交的短消息將附加到指定的消息。 _git fmt-merge-msg_ 命令可用于為自動 _git merge_ 調用提供良好的默認值。自動消息可以包括分支描述。 ``` -F <file> ``` ``` --file=<file> ``` 讀取要用于合并提交的提交消息（如果創建了一個）。 如果指定了`--log`，則正在合并的提交的短消息將附加到指定的消息。 ``` --[no-]rerere-autoupdate ``` 如果可能，允許rerere機制使用自動沖突解決的結果更新索引。 ``` --abort ``` 中止當前的沖突解決過程，并嘗試重建合并前的狀態。 如果在合并開始時存在未提交的工作樹更改，則 _git merge --abort_ 在某些情況下將無法重建這些更改。因此，建議在運行 _git merge_ 之前始終提交或存儲您的更改。 當`MERGE_HEAD`存在時， _git merge --abort_ 相當于 _git reset --merge_ 。 ``` --continue ``` 在 _git merge_ 因沖突而停止后，您可以通過運行 _git merge --continue_ 來結束合并（請參閱下面的“如何解決沖突”部分）。 ``` <commit>…? ``` 提交，通常是其他分支機構，合并到我們的分支機構。指定多個提交將創建一個包含兩個以上父項的合并（被親切地稱為八達通合并）。 如果未從命令行提供任何提交，請合并當前分支配置為用作其上游的遠程跟蹤分支。另請參見本手冊頁的配置部分。 當指定`FETCH_HEAD`（并且沒有其他提交）時，通過先前調用`git fetch`進行合并而在`.git/FETCH_HEAD`文件中記錄的分支被合并到當前分支。 ## 預先檢查 在應用外部變更之前，您應該使自己的工作處于良好狀態并在本地進行，因此如果存在沖突，則不會被破壞。另見 [git-stash [1]](https://git-scm.com/docs/git-stash) 。 _git pull_ 和 _git merge_ 將停止而不做任何事情當本地未提交的更改與 _git pull_ / _git merge_ 可能需要的文件重疊時更新。 為了避免在合并提交中記錄不相關的更改，如果索引中相對于`HEAD`提交注冊了任何更改， _git pull_ 和 _git merge_ 也將中止。 （根據正在使用的合并策略，可能存在此規則的特殊狹義異常，但通常，索引必須與HEAD匹配。） 如果所有已命名的提交都已經是`HEAD`的祖先，則 _git merge_ 將提前退出并顯示“已經是最新的”消息。 ## 快速前進的合并 通常，當前分支頭是命名提交的祖先。這是最常見的情況，尤其是從 _git pull_ 調用時：您正在跟蹤上游存儲庫，您沒有提交本地更改，現在您想要更新到更新的上游修訂版。在這種情況下，不需要新的提交來存儲組合的歷史記錄;相反，`HEAD`（以及索引）更新為指向命名提交，而不創建額外的合并提交。 使用`--no-ff`選項可以抑制此行為。 ## 真正的合并 除了快速合并（見上文）之外，要合并的分支必須通過合并提交綁定在一起，合并提交將它們都作為父項。 將提交一個合并版本，以協調要合并的所有分支的更改，并將`HEAD`，索引和工作樹更新到它。只要它們不重疊，就可以在工作樹中進行修改;更新將保留它們。 如果不明顯如何協調更改，則會發生以下情況： 1. `HEAD`指針保持不變。 2. `MERGE_HEAD` ref設置為指向另一個分支頭。 3. 干凈地合并的路徑在索引文件和工作樹中都會更新。 4. 對于沖突路徑，索引文件最多可記錄三個版本：階段1存儲來自共同祖先的版本，階段2來自`HEAD`，階段3來自`MERGE_HEAD`（您可以使用`git ls-files -u`檢查階段）。工作樹文件包含“合并”程序的結果;即3路合并結果與熟悉的沖突標記`&lt;&lt;&lt;` `===` `&gt;&gt;&gt;`。 5. 沒有進行其他更改。特別是，在開始合并之前進行的本地修改將保持不變，并且它們的索引條目保持不變，即匹配`HEAD`。 如果您嘗試合并導致復雜沖突并想重新開始，則可以使用`git merge --abort`進行恢復。 ## 合并標簽 合并帶注釋（可能已簽名）的標記時，即使可以進行快進合并，Git也會始終創建合并提交，并且使用標記消息準備提交消息模板。此外，如果標記已簽名，則簽名檢查將在消息模板中報告為注釋。另見 [git-tag [1]](https://git-scm.com/docs/git-tag) 。 當您想要與導致恰好被標記的提交的工作集成時，例如，與上游發布點同步，您可能不希望進行不必要的合并提交。 在這種情況下，您可以在將標簽送入`git merge`之前自行“打開”標簽，或者在您自己沒有任何工作時通過`--ff-only`。例如 ``` git fetch origin git merge v1.2.3^0 git merge --ff-only v1.2.3 ``` ## 如何提出沖突 在合并期間，將更新工作樹文件以反映合并的結果。在對共同祖先版本所做的更改中，非重疊版本（即，您更改文件的某個區域而另一側保留該區域完整，或反之亦然）將逐字匯入最終結果中。然而，當雙方對同一區域進行更改時，Git不能隨意選擇一側而是另一側，并要求您通過將雙方所做的事情留在該區域來解決它。 默認情況下，Git使用與RCS套件中“merge”程序使用的樣式相同的樣式來呈現這樣一個沖突的hunk，如下所示： ``` Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. <<<<<<< 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. ``` 發生一對沖突變化的區域標有標記`&lt;&lt;&lt;&lt;&lt;&lt;&lt;`，`=======`和`&gt;&gt;&gt;&gt;&gt;&gt;&gt;`。 `=======`之前的部分通常是你的一面，之后的部分通常是它們的一面。 默認格式不顯示原始在沖突區域中所說的內容。你無法分辨出刪除了多少行，取而代之的是Barbie的評論。你能說的唯一一件事就是你的一方想說它很難而且你更喜歡去購物，而另一方則想要說這很容易。 通過將“merge.conflictStyle”配置變量設置為“diff3”，可以使用替代樣式。在“diff3”樣式中，上述沖突可能如下所示： ``` Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. <<<<<<< yours:sample.txt Conflict resolution is hard; let's go shopping. ||||||| Conflict resolution is hard. ======= Git makes conflict resolution easy. >>>>>>> theirs:sample.txt And here is another line that is cleanly resolved or unmodified. ``` 除`&lt;&lt;&lt;&lt;&lt;&lt;&lt;`，`=======`和`&gt;&gt;&gt;&gt;&gt;&gt;&gt;`標記外，它還使用另一個`|||||||`標記，后跟原始文本。你可以說原來只是陳述了一個事實，而你的一方只是屈服于那個陳述并放棄了，而另一方則試圖采取更積極的態度。您有時可以通過查看原始分辨率來獲得更好的分辨率。 ## 如何解決沖突 看到沖突后，你可以做兩件事： * 決定不合并。您需要的唯一清理是將索引文件重置為`HEAD`提交以反轉2.并清除由2.和3進行的工作樹更改。 `git merge --abort`可用于此目的。 * 解決沖突。 Git將標記工作樹中的沖突。將文件編輯成形狀， _git將_添加到索引中。使用 _git commit_ 或 _git merge - 繼續_來達成交易。后一個命令在調用 _git commit_ 之前檢查是否存在正在進行的（中斷）合并。 您可以使用許多工具解決沖突： * 使用mergetool。 `git mergetool`啟動圖形合并工具，它將幫助您完成合并。 * 看看差異。 `git diff`將顯示三向差異，突出顯示`HEAD`和`MERGE_HEAD`版本的變化。 * 查看每個分支的差異。 `git log --merge -p &lt;path&gt;`將首先顯示`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`合并到當前分支中，但不要自動進行新的提交： ``` $ git merge --no-commit maint ``` 當您想要包含對合并的進一步更改，或者想要編寫自己的合并提交消息時，可以使用此方法。 您應該避免濫用此選項以將重大更改隱藏到合并提交中。像碰撞版本/版本名稱這樣的小修正是可以接受的。 ## 合并戰略 合并機制（`git merge`和`git pull`命令）允許使用`-s`選項選擇后端_合并策略_。一些策略也可以采用自己的選項，可以通過向`git merge`和/或`git pull`提供`-X&lt;option&gt;`參數來傳遞。 ``` resolve ``` 這只能使用3向合并算法解析兩個頭（即當前分支和您從中拉出的另一個分支）。它試圖仔細檢測縱橫交錯的合并模糊，并且通常被認為是安全和快速的。 ``` recursive ``` 這只能使用3向合并算法解析兩個磁頭。當有多個可用于3向合并的共同祖先時，它會創建共同祖先的合并樹，并將其用作3向合并的參考樹。據報道，這會導致更少的合并沖突，而不會因為從Linux 2.6內核開發歷史記錄中進行的實際合并提交所做的測試而導致錯誤。此外，這可以檢測和處理涉及重命名的合并，但目前無法使用檢測到的副本。這是拉動或合并一個分支時的默認合并策略。 _遞歸_策略可以采用以下選項： ``` ours ``` 這個選項通過支持_我們的_版本來強制沖突的帥哥干凈地自動解決。來自與我們方不沖突的其他樹的更改將反映到合并結果中。對于二進制文件，整個內容都來自我們這邊。 這不應該與_我們的_合并策略混淆，后者甚至不會查看其他樹包含的內容。它丟棄了另一棵樹所做的一切，聲明_我們的_歷史記錄中包含了所有發生的事情。 ``` theirs ``` 這與_我們的_相反;請注意，與_我們的_不同，沒有_他們的_合并策略來混淆這個合并選項。 ``` patience ``` 使用此選項， _merge-recursive_ 花費一點額外的時間來避免由于不重要的匹配行（例如，來自不同函數的大括號）而有時發生的錯誤。當要合并的分支發生瘋狂分歧時使用此選項。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--patience`。 ``` diff-algorithm=[patience|minimal|histogram|myers] ``` 告訴 _merge-recursive_ 使用不同的diff算法，這有助于避免由于不重要的匹配行（例如來自不同函數的大括號）而發生的錯誤。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--diff-algorithm`。 ``` ignore-space-change ``` ``` ignore-all-space ``` ``` ignore-space-at-eol ``` ``` ignore-cr-at-eol ``` 為了進行三向合并，將具有指示類型的空白的行更改為未更改。與空行的其他更改混合的空白更改不會被忽略。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `-b`，`-w`，`--ignore-space-at-eol`和`--ignore-cr-at-eol`。 * 如果_他們的_版本只將空格更改引入一行，_我們的_版本被使用; * 如果_我們的_版本引入了空格更改，但_他們的_版本包含了實質性更改，_使用了他們的_版本; * 否則，合并以通常的方式進行。 ``` renormalize ``` 在解析三向合并時，這將運行虛擬簽出并檢入文件的所有三個階段。此選項適用于將分支與不同的清除過濾器或行尾規范化規則合并時使用。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 中的“合并具有不同簽入/簽出屬性的分支”。 ``` no-renormalize ``` 禁用`renormalize`選項。這會覆蓋`merge.renormalize`配置變量。 ``` no-renames ``` 關閉重命名檢測。這會覆蓋`merge.renames`配置變量。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--no-renames`。 ``` find-renames[=<n>] ``` 打開重命名檢測，可選擇設置相似性閾值。這是默認值。這會覆蓋 _merge.renames_ 配置變量。另見 [git-diff [1]](https://git-scm.com/docs/git-diff) `--find-renames`。 ``` rename-threshold=<n> ``` 已棄用`find-renames=&lt;n&gt;`的同義詞。 ``` subtree[=<path>] ``` 此選項是_子樹_策略的更高級形式，其中策略猜測兩個樹在合并時必須如何移位以相互匹配。相反，指定的路徑是前綴（或從頭開始剝離），以使兩個樹的形狀匹配。 ``` octopus ``` 這解決了具有兩個以上磁頭的情況，但拒絕執行需要手動解決的復雜合并。它主要用于將主題分支頭捆綁在一起。這是拉動或合并多個分支時的默認合并策略。 ``` ours ``` 這會解析任意數量的頭，但合并的結果樹始終是當前分支頭的樹，實際上忽略了所有其他分支的所有更改。它旨在用于取代側枝的舊發展歷史。請注意，這與_遞歸_合并策略的-Xours選項不同。 ``` subtree ``` 這是一種修改后的遞歸策略。當合并樹A和B時，如果B對應于A的子樹，則首先調整B以匹配A的樹結構，而不是讀取相同級別的樹。這種調整也是對共同的祖先樹進行的。 使用三向合并的策略（包括默認的_遞歸_），如果在兩個分支上進行了更改，但稍后在其中一個分支上進行了更改，則該更改將出現在合并結果中;有些人發現這種行為令人困惑。之所以會發生這種情況，是因為在執行合并時只考慮頭和合并基礎，而不是單個提交。因此，合并算法將恢復的更改視為完全沒有更改，而是替換更改的版本。 ## 組態 ``` merge.conflictStyle ``` 指定在合并時將沖突的帥哥寫入工作樹文件的樣式。默認為“合并”，顯示`&lt;&lt;&lt;&lt;&lt;&lt;&lt;`沖突標記，一側更改，`=======`標記，另一側更改，然后是`&gt;&gt;&gt;&gt;&gt;&gt;&gt;`標記。另一種樣式“diff3”在`=======`標記之前添加`|||||||`標記和原始文本。 ``` merge.defaultToUpstream ``` 如果在沒有任何提交參數的情況下調用merge，則通過使用存儲在其遠程跟蹤分支中的最后觀察值來合并為當前分支配置的上游分支。查詢`branch.&lt;current branch&gt;.remote`命名的遠程分支的`branch.&lt;current branch&gt;.merge`值，然后通過`remote.&lt;remote&gt;.fetch`將它們映射到相應的遠程跟蹤分支，并合并這些跟蹤分支的提示。 ``` merge.ff ``` 默認情況下，Git在合并作為當前提交的后代的提交時不會創建額外的合并提交。相反，當前分支的提示是快進的。當設置為`false`時，此變量告訴Git在這種情況下創建額外的合并提交（相當于從命令行提供`--no-ff`選項）。設置為`only`時，僅允許此類快進合并（相當于從命令行提供`--ff-only`選項）。 ``` merge.verifySignatures ``` 如果為true，則等效于--verify-signatures命令行選項。有關詳細信息，請參閱 [git-merge [1]](https://git-scm.com/docs/git-merge) 。 ``` merge.branchdesc ``` 除分支名稱外，還使用與其關聯的分支描述文本填充日志消息。默認為false。 ``` merge.log ``` 除了分支名稱之外，還要從正在合并的實際提交中填充最多具有指定數量的單行描述的日志消息。默認為false，true是20的同義詞。 ``` merge.renameLimit ``` 合并期間執行重命名檢測時要考慮的文件數;如果未指定，則默認為diff.renameLimit的值。如果關閉重命名檢測，此設置無效。 ``` merge.renames ``` Git是否以及如何檢測重命名。如果設置為“false”，則禁用重命名檢測。如果設置為“true”，則啟用基本重命名檢測。默認為diff.renames的值。 ``` merge.renormalize ``` 告訴Git，存儲庫中文件的規范表示隨著時間的推移而發生了變化（例如，早期的提交記錄了帶有CRLF行結尾的文本文件，但最近提交了使用LF行結尾的文本文件）。在這樣的存儲庫中，Git可以在執行合并之前將提交中記錄的數據轉換為規范形式，以減少不必要的沖突。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 中的“合并具有不同簽入/簽出屬性的分支”部分。 ``` merge.stat ``` 是否在合并結束時打印ORIG_HEAD和合并結果之間的diffstat。默認為True。 ``` merge.tool ``` 控制 [git-mergetool [1]](https://git-scm.com/docs/git-mergetool) 使用的合并工具。下面的列表顯示了有效的內置值。任何其他值都被視為自定義合并工具，并且需要定義相應的mergetool。&lt; tool&gt; .cmd變量。 ``` merge.guitool ``` 當指定-g / - gui標志時，控制 [git-mergetool [1]](https://git-scm.com/docs/git-mergetool) 使用哪個合并工具。下面的列表顯示了有效的內置值。任何其他值都被視為自定義合并工具，并且需要定義相應的mergetool。&lt; guitool&gt; .cmd變量。 * araxis * 公元前 * BC3 * codecompare * deltawalker * diffmerge * 擴散 * ecmerge * 出現 * examdiff * guiffy * gvimdiff * gvimdiff2 * gvimdiff3 * kdiff3 * 合并 * 了opendiff * p4merge * tkdiff * 如果TortoiseMerge * vimdiff同時 * vimdiff2 * vimdiff3 * 的WinMerge * xxdiff ``` merge.verbosity ``` 控制遞歸合并策略顯示的輸出量。如果檢測到沖突，則0級除了最終錯誤消息外不輸出任何內容。級別1僅輸出沖突，輸出2個沖突和文件更改。 5級及以上輸出調試信息。默認值為2級。可以被`GIT_MERGE_VERBOSITY`環境變量覆蓋。 ``` merge.<driver>.name ``` 為自定義低級合并驅動程序定義一個人類可讀的名稱。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 。 ``` merge.<driver>.driver ``` 定義實現自定義低級合并驅動程序的命令。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 。 ``` merge.<driver>.recursive ``` 命名在共同祖先之間執行內部合并時使用的低級合并驅動程序。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 。 ``` branch.<name>.mergeOptions ``` 設置合并到分支&lt; name&gt;的默認選項。語法和支持的選項與 _git merge_ 的相同，但目前不支持包含空格字符的選項值。 ## 也可以看看 [git-fmt-merge-msg [1]](https://git-scm.com/docs/git-fmt-merge-msg) ， [git-pull [1]](https://git-scm.com/docs/git-pull) ， [gitattributes [5]](https://git-scm.com/docs/gitattributes) ， [git-reset [1]](https://git-scm.com/docs/git-reset) ， [git-diff [1]](https://git-scm.com/docs/git-diff) ， [git-ls-files [1]](https://git-scm.com/docs/git-ls-files) ， [git-add [1]](https://git-scm.com/docs/git-add) ， [git- rm [1]](https://git-scm.com/docs/git-rm) ， [git-mergetool [1]](https://git-scm.com/docs/git-mergetool) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件