溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹git中的merge指的是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
在git中，merge的意思為“合并”，該命令是用于將兩個或兩個以上的開發歷史合并在一起的操作；merge命令可用于git-pull中，來整合另一代碼倉庫中的變化；也可用于從一個分支到另一個分支的合并中。
本教程操作環境：Windows7系統、Git2.30.0版、Dell G3電腦。
Git的git-merge是在Git中頻繁使用的一個命令，很多人都覺得git合并是一個非常麻煩的事情，一不小心就會遇到丟失代碼的問題，從而對git望而卻步。本文基于Git 2.8.2對git-merge命令進行完整詳細的介紹，特別是關于交叉合并所帶來的代碼遺失問題，在文末給出自己的建議，希望能夠幫助到git的使用者。本文所介紹的內容基于Git 2.8.2
git-merge命令是用于將兩個或兩個以上的開發歷史合并在一起的操作，通常也可寫作：git merge。
在git-merge命令中，有以下三種使用參數：
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
git merge <msg> HEAD <commit>...
git merge --abort
git-merge命令是用于從指定的commit(s)合并到當前分支的操作。
注：這里的指定commit(s)是指從這些歷史commit節點開始，一直到當前分開的時候。
git-merge命令有以下兩種用途：
用于git-pull中，來整合另一代碼倉庫中的變化（即：git pull = git fetch + git merge）
用于從一個分支到另一個分支的合并
假設下面的歷史節點存在，并且當前所在的分支為“master”：
那么git merge topic命令將會把在master分支上二者共同的節點（E節點）之后分離的節點（即topic分支的A B C節點）重現在master分支上，直到topic分支當前的commit節點（C節點），并位于master分支的頂部。并且沿著master分支和topic分支創建一個記錄合并結果的新節點，該節點帶有用戶描述合并變化的信息。
即下圖中的H節點，C節點和G節點都是H節點的父節點。
git merge <msg> HEAD <commit>...命令該命令的存在是由于歷史原因，在新版本中不應該使用它，應該使用git merge -m <msg> <commit>....進行替代
git merge --abort命令該命令僅僅在合并后導致沖突時才使用。git merge --abort將會拋棄合并過程并且嘗試重建合并前的狀態。但是，當合并開始時如果存在未commit的文件，git merge --abort在某些情況下將無法重現合并前的狀態。（特別是這些未commit的文件在合并的過程中將會被修改時）
警告：運行
git-merge時含有大量的未commit文件很容易讓你陷入困境，這將使你在沖突中難以回退。因此非常不鼓勵在使用git-merge時存在未commit的文件，建議使用git-stash命令將這些未commit文件暫存起來，并在解決沖突以后使用git stash pop把這些未commit文件還原出來。
本部分用于介紹git-merge命令中使用的參數
--commit和--no-commit--commit參數使得合并后產生一個合并結果的commit節點。該參數可以覆蓋--no-commit。--no-commit參數使得合并后，為了防止合并失敗并不自動提交，能夠給使用者一個機會在提交前審視和修改合并結果。
--edit和-e以及--no-edit--edit和-e用于在成功合并、提交前調用編輯器來進一步編輯自動生成的合并信息。因此使用者能夠進一步解釋和判斷合并的結果。--no-edit參數能夠用于接受自動合并的信息（通常情況下并不鼓勵這樣做）。
如果你在合并時已經給定了
-m參數（下文介紹），使用--edit（或-e）依然是有用的，這將在編輯器中進一步編輯-m所含的內容。
舊版本的節點可能并不允許用戶去編輯合并日志信息。
--ff命令--ff是指fast-forward命令。當使用fast-forward模式進行合并時，將不會創造一個新的commit節點。默認情況下，git-merge采用fast-forward模式。
關于fast-forward模式的詳細解釋，請看我的另一篇文章：一個成功的Git分支模型的“關于fast forward”一節。
--no-ff命令即使可以使用fast-forward模式，也要創建一個新的合并節點。這是當git merge在合并一個tag時的默認行為。
--ff-only命令除非當前HEAD節點已經up-to-date（更新指向到最新節點）或者能夠使用fast-forward模式進行合并，否則的話將拒絕合并，并返回一個失敗狀態。
--log[=<n>]和 --no-log--log[=<n>]將在合并提交時，除了含有分支名以外，還將含有最多n個被合并commit節點的日志信息。--no-log并不會列出該信息。
--stat, -n, --no-stat命令--stat參數將會在合并結果的末端顯示文件差異的狀態。文件差異的狀態也可以在git配置文件中的merge.stat配置。
相反，-n, --no-stat參數將不會顯示該信息。
--squash 和--no-squash--squash 當一個合并發生時，從當前分支和對方分支的共同祖先節點之后的對方分支節點，一直到對方分支的頂部節點將會壓縮在一起，使用者可以經過審視后進行提交，產生一個新的節點。
注意1:該參數和
--no-ff沖突
注意2:該參數使用后的結果類似于在當前分支提交一個新節點。在某些情況下這個參數非常有用，例如使用Git Flow時（關于Git Flow，請參考：一個成功的Git分支模型），功能分支在進行一個功能需求的研發時，開發者可能在本地提交了大量且無意義的節點，當需要合并到develop分支時，可能僅僅需要用一個新的節點來表示這一長串節點的修改內容，這時
--squash命令將會發揮作用。此外，如果功能分支的多次提交并不是瑣碎而都是有意義的，使用--no-ff命令更為合適。--no-squash的作用正好相反。
-s <strategy>和 --strategy=<strategy>-s <strategy>和 --strategy=<strategy>用于指定合并的策略。默認情況如果沒有指定該參數，git將按照下列情況采用默認的合并策略：
合并節點只含有單個父節點時（如采用fast-forward模式時），采用recursive策略（下文介紹）。
合并節點含有多個父節點時(如采用no-fast-forward模式時)，采用octopus策略（下文介紹）。
-X <option>和 --strategy-option=<option>在-s <strategy>時指定該策略的具體參數（下文介紹）。
--verify-signatures, --no-verify-signatures用于驗證被合并的節點是否帶有GPG簽名，并在合并中忽略那些不帶有GPG簽名驗證的節點。
(以下引用摘自一篇轉載的文章，由于我沒有找到原作者，因此無法提供原作者信息和原文鏈接，如果有所侵權請私信或者評論告知，我將刪除以下引用內容。)
GPG是加密軟件，可以使用GPG生成的公鑰在網上安全的傳播你的文件、代碼。
為什么說安全的？以Google所開發的repo為例，repo即采用GPG驗證的方式，每個里程碑tag都帶有GPG加密驗證，假如在里程碑v1.12.3處你想要做修改，修改完后將這個tag刪除，然后又創建同名tag指向你的修改點，這必然是可以的。但是，在你再次clone你修改后的項目時，你會發現，你對此里程碑tag的改變不被認可，驗證失敗，導致你的修改在這里無法正常實現。這就是GPG驗證的作用，這樣就能夠保證項目作者（私鑰持有者）所制定的里程碑別人將無法修改。那么，就可以說，作者的代碼是安全傳播的。
為什么會有這種需求？一個項目從開發到發布，再到后期的更新迭代，一定會存在若干的穩定版本與開發版本（存在不穩定因素）。作為項目發起者、持有者，有權定義他（們）所認可的穩定版本，這個穩定版本，將不允許其他開發者進行改動。還以Google的repo項目為例，項目所有者定義項目開發過程中的點A為穩定版v1.12.3，那么用戶在下載v1.12.3版本后，使用的肯定是A點所生成的項目、產品，就算其他開發者能夠在本地對v1.12.3進行重新指定，指定到他們修改后的B點，但是最終修改后的版本給用戶用的時候，會出現GPG簽名驗證不通過的問題，也就是說這樣的修改是不生效的。
—summary,--no-summary和--stat與 --no-stat相似，并將在未來版本移除。
-q和 --quiet靜默操作，不顯示合并進度信息。
-v和 --verbose顯示詳細的合并結果信息。
--progress和 --no-progress切換是否顯示合并的進度信息。如果二者都沒有指定，那么在標準錯誤發生時，將在連接的終端顯示信息。請注意，并不是所有的合并策略都支持進度報告。
-S[<keyid>]和 --gpg-sign[=<keyid>]GPG簽名。
-m <msg>設置用于創建合并節點時的提交信息。
如果指定了--log參數，那么commit節點的短日志將會附加在提交信息里。
--[no-]rerere-autoupdatererere即reuse recorded resolution，重復使用已經記錄的解決方案。它允許你讓 Git 記住解決一個塊沖突的方法，這樣在下一次看到相同沖突時，Git 可以為你自動地解決它。
--abort拋棄當前合并沖突的處理過程并嘗試重建合并前的狀態。
在合并外部分支時，你應當保持自己分支的整潔，否則的話當存在合并沖突時將會帶來很多麻煩。
為了避免在合并提交時記錄不相關的文件，如果有任何在index所指向的HEAD節點中登記的未提交文件，git-pull和git-merge命令將會停止。
通常情況下分支合并都會產生一個合并節點，但是在某些特殊情況下例外。例如調用git pull命令更新遠端代碼時，如果本地的分支沒有任何的提交，那么沒有必要產生一個合并節點。這種情況下將不會產生一個合并節點，HEAD直接指向更新后的頂端代碼，這種合并的策略就是fast-forward合并。
除了上文所提到的fast-forward合并模式以外，被合并的分支將會通過一個合并節點和當前分支綁在一起，該合并節點同時擁有合并前的當前分支頂部節點和對方分支頂部節點，共同作為父節點。
一個合并了的版本將會使所有相關分支的變化一致，包括提交節點，HEAD節點和index指針以及節點樹都會被更新。只要這些節點中的文件沒有重疊的地方，那么這些文件的變化都會在節點樹中改動并更新保存。
如果無法明顯地合并這些變化，將會發生以下的情況：
HEAD指針所指向的節點保持不變
MERGE_HEAD指針被置于其他分支的頂部
已經合并干凈的路徑在index文件和節點樹中同時更新
對于沖突路徑，index文件記錄了三個版本：版本1記錄了二者共同的祖先節點，版本2記錄了當前分支的頂部，即HEAD，版本3記錄了MERGE_HEAD。節點樹中的文件包含了合并程序運行后的結果。例如三路合并算法會產生沖突。
其他方面沒有任何變化。特別地，你之前進行的本地修改將繼續保持原樣。
如果你嘗試了一個導致非常復雜沖突的合并，并想重新開始，那么可以使用git merge --abort
關于三路合并算法：
三路合并算法是用于解決沖突的一種方式，當產生沖突時，三路合并算法會獲取三個節點：本地沖突的B節點，對方分支的C節點，B，C節點的共同最近祖先節點A。三路合并算法會根據這三個節點進行合并。具體過程是，B，C節點和A節點進行比較，如果B，C節點的某個文件和A節點中的相同，那么不產生沖突；如果B或C只有一個和A節點相比發生變化，那么該文件將會采用該變化了的版本；如果B和C和A相比都發生了變化，且變化不相同，那么則需要手動去合并;如果B，C都發生了變化，且變化相同，那么并不產生沖突，會自動采用該變化的版本。最終合并后會產生D節點，D節點有兩個父節點，分別為B和C。
當合并一個tag時，Git總是創建一個合并的提交，即使這時能夠使用fast-forward模式。該提交信息的模板預設為該tag的信息。額外地，如果該tag被簽名，那么簽名的檢測信息將會附加在提交信息模板中。
當產生合并沖突時，該部分會以<<<<<<<, =======和 >>>>>>>表示。在=======之前的部分是當前分支這邊的情況，在=======之后的部分是對方分支的情況。
在看到沖突以后，你可以選擇以下兩種方式：
決定不合并。這時，唯一要做的就是重置index到HEAD節點。git merge --abort用于這種情況。
解決沖突。Git會標記沖突的地方，解決完沖突的地方后使用git add加入到index中，然后使用git commit產生合并節點。
你可以用以下工具來解決沖突:
使用合并工具。git mergetool將會調用一個可視化的合并工具來處理沖突合并。
查看差異。git diff將會顯示三路差異（三路合并中所采用的三路比較算法）。
查看每個分支的差異。git log --merge -p <path>將會顯示HEAD版本和MERGE_HEAD版本的差異。
查看合并前的版本。git show :1:文件名顯示共同祖先的版本，git show :2:文件名顯示當前分支的HEAD版本，git show :3:文件名顯示對方分支的MERGE_HEAD版本。
Git可以通過添加-s參數來指定合并的策略。一些合并策略甚至含有自己的參數選項，通過-X<option>設置這些合并策略的參數選項。(不要忘記，合并可以在git merge和git pull命令中發生，因此該合并策略同樣適用于git pull)。
僅僅使用三路合并算法合并兩個分支的頂部節點（例如當前分支和你拉取下來的另一個分支）。這種合并策略遵循三路合并算法，由兩個分支的HEAD節點以及共同子節點進行三路合并。
當然，真正會困擾我們的其實是交叉合并（criss-cross merge）這種情況。所謂的交叉合并，是指共同祖先節點有多個的情況，例如在兩個分支合并時，很有可能出現共同祖先節點有兩個的情況發生，這時候無法按照三路合并算法進行合并（因為共同祖先節點不唯一）。resolve策略在解決交叉合并問題時是這樣處理的，這里參考《Version Control with Git》：
In criss-cross merge situations, where there is more than one possible merge basis, the resolve strategy works like this: pick one of the possible merge bases, and hope for the best. This is actually not as bad as it sounds. It often turns out that the users have been working on different parts of the code. In that case, Git detects that it's remerging some changes that are already in place and skips the duplicate changes, avoiding the conflict. Or, if these are slight changes that do cause conflict, at least the conflict should be easy for the developer to handle
這里簡單翻譯一下：在交叉合并的情況時有一個以上的合并基準點（共同祖先節點），resolve策略是這樣工作的：選擇其中一個可能的合并基準點并期望這是合并最好的結果。實際上這并沒有聽起來的那么糟糕。通常情況下用戶修改不同部分的代碼，在這種情況下，很多的合并沖突其實是多余和重復的。而使用resolve進行合并時，產生的沖突也較易于處理，真正會遺失代碼的情況很少。
僅僅使用三路合并算法合并兩個分支。和resolve不同的是，在交叉合并的情況時，這種合并方式是遞歸調用的，從共同祖先節點之后兩個分支的不同節點開始遞歸調用三路合并算法進行合并，如果產生沖突，那么該文件不再繼續合并，直接拋出沖突；其他未產生沖突的文件將一直執行到頂部節點。額外地，這種方式也能夠檢測并處理涉及修改文件名的操作。這是git合并和拉取代碼的默認合并操作。
recursive合并策略有以下參數：
該參數將強迫沖突發生時，自動使用當前分支的版本。這種合并方式不會產生任何困擾情況，甚至git都不會去檢查其他分支版本所包含的沖突內容這種方式會拋棄對方分支任何沖突內容。
正好和ours相反。
theirs和ours參數都適用于合并二進制文件沖突的情況。
在這種參數下，git merge-recursive花費一些額外的時間來避免錯過合并一些不重要的行（如函數的括號）。如果當前分支和對方分支的版本分支分離非常大時，建議采用這種合并方式。
diff-algorithm=[patience|minimal|histogram|myers]告知git merge-recursive使用不同的比較算法。
ignore-space-change, ignore-all-space, ignore-space-at-eol根據指定的參數來對待空格沖突。
如果對方的版本僅僅添加了空格的變化，那么沖突合并時采用我們自己的版本
如果我們的版本含有空格，但是對方的版本包含大量的變化，那么沖突合并時采用對方的版本
采用正常的處理過程
no-renames關閉重命名檢測。
subtree[=<path>]該選項是subtree合并策略的高級形式，將會猜測兩顆節點樹在合并的過程中如何移動。不同的是，指定的路徑將在合并開始時除去，以使得其他路徑能夠在尋找子樹的時候進行匹配。（關于subtree合并策略詳見下文）
這種合并方式用于兩個以上的分支，但是在遇到沖突需要手動合并時會拒絕合并。這種合并方式更適合于將多個分支捆綁在一起的情況，也是多分支合并的默認合并策略。
這種方式可以合并任意數量的分支，但是節點樹的合并結果總是當前分支所沖突的部分。這種方式能夠在替代舊版本時具有很高的效率。請注意，這種方式和recursive策略下的ours參數是不同的。
subtree是修改版的recursive策略。當合并樹A和樹B時，如果B是A的子樹，B首先調整至匹配A的樹結構，而不是讀取相同的節點。
在使用三路合并的策略時（指默認的recursive策略），如果一個文件（或一行代碼）在當前分支和對方分支都產生變化，但是稍后又在其中一個分支回退，那么這種回退的變化將會在結果中體現。這一點可能會使一些人感到困惑。這是由于在合并的過程中，git僅僅關注共同祖先節點以及兩個分支的HEAD節點，而不是兩個分支的所有節點。因此，合并算法將會把被回退的部分認為成沒有變化，這樣，合并后的結果就會變為另一個分支中變化的部分。
關于git中的merge指的是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
