?
This document uses PHP Chinese website manual Release
git-merge - Join two or more development histories together
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>] [<commit>…]git merge --abort git merge --continue
將已命名的提交(從歷史記錄與當(dāng)前分支分離的時間以來)的更改合并到當(dāng)前分支中。該命令用于git pull
合并另一個存儲庫中的更改,并可用于手動合并從一個分支到另一個分支的更改。
假設(shè)存在以下歷史記錄,并且當(dāng)前分支是“ master
”:
A---B---C topic / D---E---F---G master
然后“ git merge topic
”將重播在topic
分支上發(fā)生的變化,因為它從master
(即E
)分支到其當(dāng)前的commit(C
)之上master
,并且將結(jié)果記錄在新的提交中以及兩個父提交的名稱和日志消息來自描述更改的用戶。
A---B---C topic / \ D---E---F---G---H master
第二個語法(“ git merge --abort
”)只能在合并導(dǎo)致沖突后才能運行。git merge --abort
將中止合并過程并嘗試重新構(gòu)建合并前狀態(tài)。但是,如果在合并開始時發(fā)生未提交的更改(尤其是在合并開始后進一步修改這些更改),git merge --abort
則在某些情況下將無法重建原始(合并前)更改。因此:
警告:git merge
不鼓勵使用不平凡的未提交更改:盡管可能,但可能會讓您處于難以在沖突情況下退出的狀態(tài)。
第四種語法(“ git merge --continue
”)只能在合并導(dǎo)致沖突后才能運行。
--commit --no-commit
執(zhí)行合并并提交結(jié)果。這個選項可以用來覆蓋--no-commit。
使用--no-commit執(zhí)行合并,但假裝合并失敗并且不自動提交,以使用戶有機會在提交之前檢查并進一步調(diào)整合并結(jié)果。
--edit -e --no-edit
在提交成功的機械合并之前調(diào)用編輯器來進一步編輯自動生成的合并消息,以便用戶可以解釋并驗證合并。該--no-edit
選項可用于接受自動生成的消息(這通常是不鼓勵的)。該--edit
(或-e
)選項仍然是有用的,如果你給同一個消息草稿-m
命令行選項,并希望在編輯器中編輯。
較舊的腳本可能取決于不允許用戶編輯合并日志消息的歷史行為。他們將在運行時看到編輯器打開git merge
。為了更容易地將這些腳本調(diào)整為更新的行為,GIT_MERGE_AUTOEDIT
可以將環(huán)境變量設(shè)置為no
它們的開頭。
--ff
當(dāng)合并解析為快進時,只更新分支指針,而不創(chuàng)建合并提交。這是默認(rèn)行為。
--no-ff
即使合并解析為快進,也可以創(chuàng)建合并提交。這是合并注釋(可能有符號)標(biāo)記時的默認(rèn)行為。
--ff-only
拒絕合并并以非零狀態(tài)退出,除非電流HEAD
已經(jīng)是最新的或合并可以解決為快進。
--log=<n> --no-log
除了分支名稱之外,還可以用來自至多<n>實際提交的單行描述來填充日志消息。另請參閱git-fmt-merge-msg [1]。
使用--no-log不會列出要合并的實際提交的單行描述。
--stat -n --no-stat
在合并結(jié)束時顯示diffstat。diffstat也由配置選項merge.stat控制。
使用-n或--no-stat不會在合并結(jié)束時顯示diffstat。
--squash --no-squash
生成工作樹和索引狀態(tài),就像發(fā)生真正的合并(合并信息除外)一樣,但實際上并未進行提交,移動HEAD
或記錄$GIT_DIR/MERGE_HEAD
(以導(dǎo)致下一個git commit
命令創(chuàng)建合并提交)。這允許您在當(dāng)前分支上創(chuàng)建一個單獨的提交,其效果與合并另一個分支相同(或者在章魚的情況下更多)。
用--no-squash執(zhí)行合并并提交結(jié)果。這個選項可以用來覆蓋--squash。
-s <strategy> --strategy=<strategy>
使用給定的合并策略; 可以多次提供,以按照他們應(yīng)該嘗試的順序指定它們。如果沒有-s
選項,則使用內(nèi)置策略列表(否則git merge-recursive
合并單個頭部時git merge-octopus
)。
-X <option> --strategy-option=<option>
將合并策略特定選項傳遞給合并策略。
--verify-signatures --no-verify-signatures
驗證被合并的分支的提示提交是否使用有效密鑰簽名,即具有有效uid的密鑰:在默認(rèn)信任模型中,這意味著簽名密鑰已由可信密鑰簽名。如果側(cè)分支的提示提交未使用有效密鑰進行簽名,則會中止合并。
--summary --no-summary
同義詞--stat和--no-stat; 這些已被棄用,并將在未來被刪除。
-q --quiet
安靜地操作。意味著 --no-progress
-v --verbose
詳細(xì)。
--progress --no-progress
明確地打開/關(guān)閉進度。如果沒有指定,如果標(biāo)準(zhǔn)錯誤連接到終端,則顯示進度。請注意,并非所有合并策略都可能支持進度報告。
--allow-unrelated-histories
默認(rèn)情況下,git merge
命令拒絕合并不共享祖先的歷史記錄。在合并兩個獨立開始他們的生活的項目的歷史時,可以使用此選項來覆蓋此安全性。由于這是非常罕見的情況,因此默認(rèn)情況下不存在配置變量,因此不會添加該變量。
-S<keyid> --gpg-sign=<keyid>
GPG-sign合并提交。該keyid
參數(shù)是可選的,并且默認(rèn)為提交者身份; 如果指定,它必須粘貼到選項沒有空格。
-m <msg>
設(shè)置要用于合并提交的提交消息(以防創(chuàng)建)。
如果--log
指定,則將合并的提交短記錄附加到指定的消息。
該git fmt-merge-msg
命令可用于為自動git merge
調(diào)用提供良好的默認(rèn)值。自動化消息可以包含分支描述。
--no-rerere-autoupdate
如果可能的話,允許rerere機制用自動沖突解決的結(jié)果更新索引。
--abort
中止當(dāng)前的沖突解決過程,并嘗試重新構(gòu)建預(yù)合并狀態(tài)。
如果在合并開始時存在未提交的工作樹更改,git merge --abort
則在某些情況下無法重建這些更改。因此建議在運行之前始終提交或存儲更改git merge
。
git merge --abort
相當(dāng)于git reset --merge
何時MERGE_HEAD
存在。
--continue
git merge
由于沖突停止后,您可以通過運行來結(jié)束合并git merge --continue
(請參閱下面的“如何解決沖突”一節(jié))。
<commit>…
通常,其他分行負(fù)責(zé)人將合并到我們的分行。指定多個提交將與兩個以上的父母創(chuàng)建合并(親切地稱為Octopus合并)。
如果沒有從命令行提交提交,則合并當(dāng)前分支被配置為用作其上游的遠(yuǎn)程跟蹤分支。另見本手冊頁面的配置部分。
當(dāng)FETCH_HEAD
(并且沒有其他提交)被指定時,.git/FETCH_HEAD
通過先前調(diào)用git fetch
合并記錄在文件中的分支被合并到當(dāng)前分支。
在應(yīng)用外部變更之前,您應(yīng)該完成自己的工作,并在本地承諾,因此如果發(fā)生沖突,它不會被破壞。另見git-stash [1]。git pull
并git merge
會停止,而不做任何事情時,本地提交的更改與文件重疊git pull
/ git merge
可能需要更新。
為了避免在合并提交中記錄不相關(guān)的更改,git pull
并且git merge
如果在索引中相對于HEAD
提交注冊了任何更改,也會中止。(一個例外是當(dāng)已更改的索引條目處于已經(jīng)合并的狀態(tài)時。)
如果所有已命名的提交都已經(jīng)是祖先HEAD
,git merge
則會提前退出,并顯示“已更新”消息。
通常當(dāng)前分支頭是命名提交的祖先。這是最常見的情況,特別是在從git pull
以下情況調(diào)用時:您正在跟蹤上游存儲庫,您沒有提交本地更改,現(xiàn)在您想更新為更新的上游修訂版。在這種情況下,不需要新的提交來存儲組合的歷史; 相反,HEAD
(與索引一起)更新為指向指定的提交,而不創(chuàng)建額外的合并提交。
該行為可以通過該--no-ff
選項進行抑制。
除了在快進合并中(見上文),要合并的分支必須通過合并提交綁定在一起,合并提交將它們都作為其父項。
提交一個合并版本來協(xié)調(diào)所有要合并的分支的更改,并將您的HEAD
索引和工作樹更新為它。只要不重疊,可以在工作樹中進行修改; 更新將保留它們。
如果不清楚如何協(xié)調(diào)更改,則會發(fā)生以下情況:
該HEAD
指針保持不變。
該MERGE_HEAD
ref被設(shè)置為指向另一個分支頭。
干凈合并的路徑在索引文件和工作樹中都會更新。
對于沖突的路徑,索引文件最多可以記錄三個版本:第1階段存儲公共祖先的版本,第2階段的版本HEAD
和第3 階段的版本MERGE_HEAD
(可以檢查階段git ls-files -u
)。工作樹文件包含“合并”程序的結(jié)果; 即3路合并結(jié)果與熟悉的沖突標(biāo)記<<<
===
>>>
。
沒有其他更改。特別是,在開始合并之前進行的本地修改將保持不變,并且它們的索引條目保持原樣,即匹配HEAD
。
如果您嘗試導(dǎo)致復(fù)雜沖突并想重新開始的合并,則可以使用恢復(fù)git merge --abort
。
合并注釋(也可能是簽名)標(biāo)記時,即使可以進行快進合并,Git也會始終創(chuàng)建合并提交,并且提交消息模板是使用標(biāo)記消息準(zhǔn)備的。另外,如果標(biāo)簽已簽名,則簽名檢查會作為消息模板中的注釋報告。另請參閱git-tag [1]。
當(dāng)您只想將導(dǎo)致正好被標(biāo)記的提交的工作集成時,例如與上游發(fā)行版同步時,您可能不想進行不必要的合并提交。
在這種情況下,您可以在喂食之前自己“unwrap”標(biāo)簽git merge
,或者--ff-only
在您自己沒有任何工作時通過。例如
git fetch origin git merge v1.2.3^0git merge --ff-only v1.2.3
在合并期間,更新工作樹文件以反映合并結(jié)果。在對共同祖先版本進行的更改中,不重疊的(即,您更改了文件的某個區(qū)域,而另一側(cè)完全保留該區(qū)域,或反之亦然)最終結(jié)果逐字記錄。但是,當(dāng)雙方都對同一地區(qū)進行更改時,Git不能隨意選擇一邊而不是另一邊,并要求您通過將雙方對該區(qū)域的干涉解決。
默認(rèn)情況下,Git使用與RCS套件中的“合并”程序使用的風(fēng)格相同的風(fēng)格來呈現(xiàn)這樣一個沖突的大塊,如下所示:
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.
其中一對相互矛盾的變化發(fā)生的區(qū)域標(biāo)有標(biāo)記<<<<<<<
,=======
和>>>>>>>
。之前的部分=======
通常是你的一面,而之后的部分通常是他們的一面。
默認(rèn)格式不顯示原始在沖突區(qū)域中所說的內(nèi)容。你不知道有多少行被刪除, 取而代之的是芭比的評論在你身邊。你唯一能說的是, 你的一方想說這是很難的, 你寧愿去購物, 而另一方想聲稱這是容易的。
通過將“merge.conflictStyle”配置變量設(shè)置為“diff3”,可以使用其他樣式。在“diff3”風(fēng)格中,上述沖突可能如下所示:
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.
除了<<<<<<<
,=======
和>>>>>>>
標(biāo)志,它使用另一個|||||||
后跟原文標(biāo)記。你可以說,原文只是陳述了一個事實,你方只是放棄了這個陳述而放棄了,而另一方則試圖采取更積極的態(tài)度。有時您可以通過查看原件來獲得更好的分辨率。
看到?jīng)_突后,你可以做兩件事:
決定不合并。您需要的唯一清理操作是將索引文件重置為HEAD
提交以反向2.并清除由2.和3所做的工作樹更改。git merge --abort
可以用于此。
解決沖突。Git將標(biāo)記工作樹中的沖突。將這些文件編輯為形狀,git add
并將其轉(zhuǎn)換為索引。使用git commit
或git merge --continue
密封交易。后一個命令在調(diào)用之前檢查是否存在正在進行的(中斷的)合并git commit
。
您可以通過許多工具解決沖突:
使用mergetool。git mergetool
啟動一個圖形化的合并工具,這將通過合并工作。
看看差異。git diff
將顯示三方差異,突出顯示來自版本HEAD
和MERGE_HEAD
版本的更改。
看看每個分支的差異。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
當(dāng)前分支的頂部,使分支合并:$ git merge fixes enhancements
obsolete
使用ours
合并策略將分支合并到當(dāng)前分支中:$ git merge -s我們的過時的
將分支合并maint
到當(dāng)前分支中,但不要自動創(chuàng)建新的提交:$ git merge --no-commit maint
當(dāng)您想要對合并進行進一步的更改,或者想要編寫自己的合并提交消息時,可以使用此選項。
You should refrain from abusing this option to sneak substantial changes into a merge commit. Small fixups like bumping release/version name would be acceptable.
合并機制(git merge
和git pull
命令)允許merge strategies
使用-s
選項選擇后端。一些策略也可以采取他們自己的選擇,這可以通過給出-X<option>
參數(shù)git merge
和/或通過git pull
。
resolve
這只能使用3路合并算法解析兩個頭(即當(dāng)前分支和另一個分支)。它試圖仔細(xì)檢測交叉融合歧義,并被認(rèn)為通常是安全和快速的。
recursive
這只能使用3路合并算法來解析兩個頭。當(dāng)有多個可用于3路合并的共同祖先時,它將創(chuàng)建共同祖先的合并樹并將其用作3路合并的參考樹。據(jù)報道,這會導(dǎo)致更少的合并沖突,而不會因從Linux 2.6內(nèi)核開發(fā)歷史記錄中進行的實際合并提交所做的測試而導(dǎo)致混淆。此外,這可以檢測并處理涉及重命名的合并。這是拉取或合并一個分支時的默認(rèn)合并策略。
該recursive
策略可以采取以下選擇:
ours
該選項強制沖突的hunk通過支持our
版本自動解決。來自另一棵與我們不沖突的樹的變化反映到合并結(jié)果。對于二進制文件,整個內(nèi)容都是從我們這邊拿來的。
這不應(yīng)與ours
合并策略混淆,合并策略甚至不會考慮其他樹包含的內(nèi)容。它丟棄了其他樹的所有內(nèi)容,聲明our
歷史包含發(fā)生在其中的所有事情。
theirs
這是相反的ours
; 請注意,與此不同的ours
是,沒有theirs
融合策略來混淆這個合并選項。
patience
使用此選項,merge-recursive
花費一點額外的時間來避免由于不重要的匹配行(例如,來自不同功能的括號)而導(dǎo)致的混淆。當(dāng)要合并的分支瘋狂地分歧時使用它。另請參閱git-diff [1] --patience
。
diff-algorithm=patience|minimal|histogram|myers
告訴merge-recursive
使用不同的差異算法,這可以幫助避免由于不重要的匹配行(例如不同功能的花括號)而發(fā)生誤合。另請參閱git-diff [1] --diff-algorithm
。
ignore-space-change ignore-all-space ignore-space-at-eol
為了三路合并的目的,將指定類型的空白的行對待不變??瞻鬃兓c其他變化混合在一起不會被忽略。另見GIT-DIFF [1] ,-b
,-w
和--ignore-space-at-eol
。
If their
version only introduces whitespace changes to a line, our
version is used;
If our
version introduces whitespace changes but their
version includes a substantial change, their
version is used;
Otherwise, the merge proceeds in the usual way.
renormalize
This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.
no-renormalize
禁用該renormalize
選項。這覆蓋merge.renormalize
配置變量。
no-renames
關(guān)閉重命名檢測。另請參閱git-diff [1] --no-renames
。
find-renames=<n>
打開重命名檢測,可選擇設(shè)置相似性閾值。這是默認(rèn)設(shè)置。另請參閱git-diff [1] --find-renames
。
rename-threshold=<n>
Deprecated synonym for find-renames=<n>
.
subtree=<path>
該選項是一種更高級的subtree
策略形式,該策略可以猜測兩個樹在合并時必須如何移動以相互匹配。相反,指定的路徑是前綴(或從開始剝離)以使兩棵樹的形狀匹配。
octopus
這解決了兩個以上負(fù)責(zé)人的情況,但拒絕執(zhí)行需要手動解決的復(fù)雜合并。它主要用于將主題分支主題捆綁在一起。這是拉取或合并多個分支時的默認(rèn)合并策略。
ours
這可以解析任意數(shù)量的頭,但合并結(jié)果樹始終是當(dāng)前分支頭的樹,有效地忽略了所有其他分支的所有更改。它是用來取代側(cè)枝的舊發(fā)展歷史。請注意,這與recursive
合并策略的-Xours選項不同。
subtree
這是一個修改后的遞歸策略。合并樹A和B時,如果B對應(yīng)于A的子樹,則首先調(diào)整B以匹配A的樹結(jié)構(gòu),而不是讀取處于同一級別的樹。這種調(diào)整也對共同的祖先樹進行。
對于使用3路合并(包括默認(rèn)值recursive
)的策略,如果在兩個分支上進行了更改,但稍后在其中一個分支上進行了恢復(fù),則該更改將出現(xiàn)在合并結(jié)果中; 有些人覺得這種行為很混亂。這是因為在執(zhí)行合并時僅考慮頭部和合并基礎(chǔ),而不是個別提交。因此,合并算法將恢復(fù)的更改視為完全沒有更改,而是替換更改后的版本。
merge.conflictStyle
指定在合并時將沖突的區(qū)塊寫入工作樹文件的樣式。默認(rèn)值是“合并”,它顯示了一個<<<<<<<
沖突標(biāo)記,一側(cè)=======
發(fā)生的變化,一個標(biāo)記,另一側(cè)發(fā)生的變化,然后是>>>>>>>
標(biāo)記。另一種樣式“diff3”在|||||||
標(biāo)記之前添加了一個標(biāo)記和原始文本=======
。
merge.defaultToUpstream
如果在沒有任何提交參數(shù)的情況下調(diào)用合并,則使用存儲在其遠(yuǎn)程跟蹤分支中的上次觀察值合并為當(dāng)前分支配置的上游分支。查詢branch.<current branch>.merge
名稱為遠(yuǎn)程命名的遠(yuǎn)程分支的值branch.<current branch>.remote
,然后將它們映射remote.<remote>.fetch
到其對應(yīng)的遠(yuǎn)程跟蹤分支,并合并這些跟蹤分支的提示。
merge.ff
默認(rèn)情況下,Git在合并作為當(dāng)前提交的后代的提交時不會創(chuàng)建額外的合并提交。相反,當(dāng)前分支的尖端被快速轉(zhuǎn)發(fā)。當(dāng)設(shè)置為false
,這個變量告訴Git在這種情況下創(chuàng)建一個額外的合并提交(相當(dāng)于--no-ff
從命令行提供選項)。設(shè)置only
為時,只允許進行這種快進合并(相當(dāng)于--ff-only
從命令行提供選項)。
merge.branchdesc
除了分支名稱之外,還可以使用與它們關(guān)聯(lián)的分支描述文本填充日志消息。默認(rèn)為false。
merge.log
除了分支名稱之外,還可以在日志消息中最多填入要合并的實際提交中指定數(shù)量的單行描述。默認(rèn)為false,true為20的同義詞。
merge.renameLimit
在合并期間執(zhí)行重命名檢測時要考慮的文件數(shù)量; 如果未指定,則默認(rèn)為diff.renameLimit的值。
merge.renormalize
告訴Git存儲庫中文件的規(guī)范表示已經(jīng)隨時間而改變(例如,較早的提交記錄具有CRLF行尾的文本文件,但最近使用LF行結(jié)尾)。在這樣的存儲庫中,Git可以在提交之前將提交中記錄的數(shù)據(jù)轉(zhuǎn)換為規(guī)范形式,然后再執(zhí)行合并以減少不必要的沖突。有關(guān)更多信息,請參閱gitattributes [5]中的“合并具有不同簽入/簽出屬性的分支”部分。
merge.stat
是否在合并結(jié)束時在ORIG_HEAD和合并結(jié)果之間打印diffstat。默認(rèn)情況下為真。
merge.tool
控制哪個合并工具由git-mergetool [1]使用。下面的列表顯示了有效的內(nèi)置值。任何其他值都被視為自定義合并工具,并要求定義相應(yīng)的mergetool。<tool> .cmd變量。
araxis
bc
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
examdiff
gvimdiff
gvimdiff2
gvimdiff3
kdiff3
meld
opendiff
p4merge
tkdiff
tortoisemerge
vimdiff
vimdiff2
vimdiff3
winmerge
xxdiff
merge.verbosity
控制遞歸合并策略顯示的輸出量。如果檢測到?jīng)_突,級別0只輸出最終的錯誤消息。1級只輸出沖突,2個輸出沖突和文件更改。5級及以上輸出調(diào)試信息。缺省值是2級??梢杂?code>GIT_MERGE_VERBOSITY環(huán)境變量覆蓋。
merge.<driver>.name
為自定義低級合并驅(qū)動程序定義一個人類可讀的名稱。有關(guān)詳細(xì)信息,請參閱gitattributes [5]。
merge.<driver>.driver
定義實現(xiàn)自定義低級別合并驅(qū)動程序的命令。有關(guān)詳細(xì)信息,請參閱gitattributes [5]。
merge.<driver>.recursive
在執(zhí)行公共祖先之間的內(nèi)部合并時,命名一個低級合并驅(qū)動程序。有關(guān)詳細(xì)信息,請參閱gitattributes [5]。
branch.<name>.mergeOptions
設(shè)置合并到分支<name>的默認(rèn)選項。語法和支持的選項與這些選項相同git merge
,但包含空白字符的選項值當(dāng)前不受支持。