本篇文章帶大家了解學習一下git分支，介紹一下使用分支的git merge命令，希望對大家有所幫助！
在Git中merge是用來把分叉的提交歷史放回到一起的方式。git merge命令用來將你之前使用git branch命令創建的分支以及在此分支上獨立開發的內容整合為一個分支。
請注意下面的所有命令都會是將其他分支合并到當前所在工作分支上。當前工作分支的內容會由于merge操作產生更新，但是目標分支則完全不受影響。再次強調，這意味著git merge通常與其他幾個git命令一起使用，包括使用git checkout命令來選擇當前工作分支，以及使用git branch -d命令來刪除已經合并過的廢棄分支。
它是如何運行的
git merge會將多個提交序列合并進一個統一的提交歷史。在最常見的使用場景中，git merge被用來合并兩個分支。在本文檔接下來的部分，我們會專注于這種合并場景。在這種場景中，git merge接受兩個commit指針，通常是兩個分支的頂部commit，然后向前追溯到這兩個分支最近的一個共同提交。一旦找到這個共同提交，Git就會創建一個新的”merge commit”，用來合并兩個分支上各自的提交序列。
比如說我們有一個功能分支由main分支派生出來，現在我們希望將這個功能分支合并回main分支。
執行合并命令會將指定分支合并到當前工作分支上，我們假設當前工作分支為main。Git根據兩個分支自行決定合并提交的算法（將在下面具體討論）。
合并commit與普通commit不一樣，因為合并commit會有兩個父提交。創建一個合并commit時Git會嘗試自動將兩個獨立的提交歷史合并為一個。不過當Git發現某一塊數據在兩邊的提交歷史中都含有變更，它將無法自動對其進行合并。這種情況被稱為版本沖突，此時Git需要人為介入調整才能繼續進行合并。
準備合并
在實際進行合并操作之前，需要進行一些準備步驟，以保證合并過程能夠順利進行。
確認接收合并的分支
執行git status命令查看當前分支的狀態，確保HEAD指正指向的是正確的接收合并的分支。如果不是，執行git checkout命令切換到正確的分支。在我們的示例中，執行git checkout main。
獲取最新的遠程提交
確保合并操作涉及的兩個分支都更新到遠程倉庫的最新狀態。執行git fetch拉取遠程倉庫的最新提交。一旦fetch操作完成，為了保證main分支與遠程分支同步，還需執行git pull命令。
合并
當上面提及的準備工作都已完備，合并就可以正式開始了。執行git merge
快進合并
當前工作分支到合并目標分支之間的提交歷史是線性路徑時，可以進行快進合并。在這種情況下，不需要真實的合并兩個分支，Git只需要把當前分支的頂端指針移動到目標分支的頂端就可以了（也就是快進的意思）。在這種情況下快進合并成功的將提交歷史合并至一處，畢竟目標分支中的提交此時都包含在當前分支的提交歷史中了。對于將功能分支快進合并到main分支的流程可以參見下圖所示：
然而快進合并在兩個分支出現分叉的情況下是不允許執行的。當目標分支相對于當前分支的提交歷史不是線性的，Git只能通過三路合并算法來決定如何對兩個分支進行合并。三路合并算法需要使用一個專用commit來整合兩邊的提交歷史。這個名詞源于Git要想生成合并commit，需要用到三個commits：兩個分支的頂端commit，以及它們的共同祖先commit。
雖然實際上可以選擇使用這些不同的合并策略，但是大多數開發者更喜歡快進合并（通過利用 rebasing 命令），尤其是用于小功能的開發或者bug修復；反之對于合并長期開發的功能分支，則更傾向于使用三路合并的方式。在第二種場景中，merge產生的合并commit會作為兩個分支合并的標志保留在提交歷史中。
接下來我們用下面第一個例子來展示如何進行快進合并。下面的命令會先創建一個新分支，在新分支上進行兩次提交，然后用快進合并把新分支合并回main分支。
#?Start?a?new?feature git?checkout?-b?new-feature?main #?Edit?some?files git?add?<file> git?commit?-m?"Start?a?feature" #?Edit?some?files git?add?<file> git?commit?-m?"Finish?a?feature" #?Merge?in?the?new-feature?branch git?checkout?main git?merge?new-feature git?branch?-d?new-feature</file></file>
這個例子中的工作流程通常用于短期功能的開發，這種開發流程更多地被當做是比較獨立的一次開發流程，與之對應的則是需要協調和管理的長期功能開發分支。
另外還需注意到，在此例中Git不會對git branch -d命令發出警告，因為new-feature的內容已經合并到主分支里了。
在某些情況下，雖然目標分支的提交歷史相對于當前分支是線性的，可以進行快進合并，但你仍然希望有一個合并commit來標志合并在此commit發生過，那么可以在執行git merge命令時使用–no-ff選項。
git?merge?--no-ff?<branch></branch>
以上命令將指定分支合并到當前分支，但總會生成一個合并commit（即便這一合并操作可以快進）。當你需要在倉庫的提交歷史中標記合并事件時這一命令相當有用。
三路合并
接下來的例子與上面比較像，但是因為main分支在feature分支向前發展的過程中，自身也發生的改變，因此在合并時需要進行三路合并。在進行大的功能開發或者有多個開發者同時進行開發時這種場景相當常見。
Start?a?new?feature git?checkout?-b?new-feature?main #?Edit?some?files git?add?<file> git?commit?-m?"Start?a?feature" #?Edit?some?files git?add?<file> git?commit?-m?"Finish?a?feature" #?Develop?the?main?branch git?checkout?main #?Edit?some?files git?add?<file> git?commit?-m?"Make?some?super-stable?changes?to?main" #?Merge?in?the?new-feature?branch git?merge?new-feature git?branch?-d?new-feature</file></file></file>
需注意在這種情況下，由于沒有辦法直接把main的頂端指針移動到new-feature分支上，因此Git無法執行快進合并。
在大多數實際工作場景中，new-feature應該是一個很大的功能，開發過程持續了相當長的時間，這也就難免同時期在main分支上也有新的提交。如果你的功能分支大小像上面的例子一樣小，則完全可以使用rebase將new-feature分支變基到main分支上，然后再執行一次快進合并。這樣也會避免在項目提交歷史中產生過多的冗余。
解決沖突
如果將要合并的兩個分支都修改了同一個而文件的同一個部分內容，Git就無法確定應該使用哪個版本的內容。當這種情況發生時，合并過程會停止在合并commit提交之前，以便給用戶留下機會手動修復這些沖突。
在Git的合并過程中，很棒的一點是它使用人們熟知的 編輯 / 暫存 / 提交 這樣的工作流程來解決沖突。當碰到合并沖突時，執行git status命令會列出哪些文件含有沖突并需要手動解決。比如說當兩個分支都修改了hello.py文件的同一部分，你會看到類似下面這樣的信息：
On?branch?main Unmerged?paths: (use?"git?add/rm?..."?as?appropriate?to?mark?resolution) both?modified:?hello.py
沖突是如何顯示的
當Git在合并過程中碰到了沖突，它會編輯受影響的文件中的相關內容，并添加視覺標記用以展示沖突中雙方在此部分的不同內容。這些視覺標記為：>>>>>>。要找到沖突發生的具體位置，在文件中搜索這些視覺標記會非常便捷地達成目的。
here?is?some?content?not?affected?by?the?conflict >>>>>>?feature?branch;
通常來說在 ====== 標記之前的內容來自于接收合并的分支，而在這之后的內容來自于要合并的分支。
一旦找到沖突的部分，就可以根據需要來修正沖突。當你完成了沖突的修復并準備好繼續進行合并，只需要執行git add命令把已經解決好沖突的文件添加暫存區，告訴Git這些沖突已經解決完畢即可。這之后就像正常提交代碼一樣執行git commit完成合并commit。這個過程跟正常情況下提交代碼是完全一樣的，也就是說對于普通開發者來說處理沖突也是小菜一碟。
還需注意合并沖突只可能出現在三路合并過程中，在快進合并中不會出現沖突。
總結
本文是關于git merge命令的概覽。在使用Git的過程中，合并是非常重要的操作。本文討論了合并操作背后的機制，以及快進合并與三路合并的區別。需要讀者記住的要點如下：
-
Git 合并流程是把不同的提交序列合并到一個統一的提交歷史中
-
Git合并過程中有兩個主要的方式：快進合并 和 三路合并
-
除非兩個提交序列中出現沖突，Git通常可以自動對提交進行合并
推薦學習：《rebasing 》
