這篇文章主要介紹“Git的merge命令實例分析”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Git的merge命令實例分析”文章能幫助大家解決問題。

創(chuàng)新互聯(lián)建站是專業(yè)的遂平網(wǎng)站建設公司，遂平接單;提供成都網(wǎng)站建設、網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行遂平網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

它是如何運行的

git merge會將多個提交序列合并進一個統(tǒng)一的提交歷史。在最常見的使用場景中，git merge被用來合并兩個分支。在本文檔接下來的部分，我們會專注于這種合并場景。在這種場景中，git merge接受兩個commit指針，通常是兩個分支的頂部commit，然后向前追溯到這兩個分支最近的一個共同提交。一旦找到這個共同提交，Git就會創(chuàng)建一個新的"merge commit"，用來合并兩個分支上各自的提交序列。

比如說我們有一個功能分支由main分支派生出來，現(xiàn)在我們希望將這個功能分支合并回main分支。

執(zhí)行合并命令會將指定分支合并到當前工作分支上，我們假設當前工作分支為main。Git根據(jù)兩個分支自行決定合并提交的算法（將在下面具體討論）。

合并commit與普通commit不一樣，因為合并commit會有兩個父提交。創(chuàng)建一個合并commit時Git會嘗試自動將兩個獨立的提交歷史合并為一個。不過當Git發(fā)現(xiàn)某一塊數(shù)據(jù)在兩邊的提交歷史中都含有變更，它將無法自動對其進行合并。這種情況被稱為版本沖突，此時Git需要人為介入調整才能繼續(xù)進行合并。

準備合并

在實際進行合并操作之前，需要進行一些準備步驟，以保證合并過程能夠順利進行。

確認接收合并的分支

執(zhí)行git status命令查看當前分支的狀態(tài)，確保HEAD指正指向的是正確的接收合并的分支。如果不是，執(zhí)行git checkout命令切換到正確的分支。在我們的示例中，執(zhí)行git checkout main。

獲取最新的遠程提交

確保合并操作涉及的兩個分支都更新到遠程倉庫的最新狀態(tài)。執(zhí)行git fetch拉取遠程倉庫的最新提交。一旦fetch操作完成，為了保證main分支與遠程分支同步，還需執(zhí)行git pull命令。

合并

當上面提及的準備工作都已完備，合并就可以正式開始了。執(zhí)行git merge 命令，其中為需要合并到當前分支的目標分支名稱。

快進合并

當前工作分支到合并目標分支之間的提交歷史是線性路徑時，可以進行快進合并。在這種情況下，不需要真實的合并兩個分支，Git只需要把當前分支的頂端指針移動到目標分支的頂端就可以了（也就是快進的意思）。在這種情況下快進合并成功的將提交歷史合并至一處，畢竟目標分支中的提交此時都包含在當前分支的提交歷史中了。

然而快進合并在兩個分支出現(xiàn)分叉的情況下是不允許執(zhí)行的。當目標分支相對于當前分支的提交歷史不是線性的，Git只能通過三路合并算法來決定如何對兩個分支進行合并。三路合并算法需要使用一個專用commit來整合兩邊的提交歷史。這個名詞源于Git要想生成合并commit，需要用到三個commits：兩個分支的頂端commit，以及它們的共同祖先commit。

雖然實際上可以選擇使用這些不同的合并策略，但是大多數(shù)開發(fā)者更喜歡快進合并（通過利用 rebasing 命令），尤其是用于小功能的開發(fā)或者bug修復；反之對于合并長期開發(fā)的功能分支，則更傾向于使用三路合并的方式。在第二種場景中，merge產生的合并commit會作為兩個分支合并的標志保留在提交歷史中。

接下來我們用下面第一個例子來展示如何進行快進合并。下面的命令會先創(chuàng)建一個新分支，在新分支上進行兩次提交，然后用快進合并把新分支合并回main分支。

# Start a new feature
git checkout -b new-feature main
# Edit some files
git add 
git commit -m "Start a feature"
# Edit some files
git add 
git commit -m "Finish a feature"
# Merge in the new-feature branch
git checkout main
git merge new-feature
git branch -d new-feature

這個例子中的工作流程通常用于短期功能的開發(fā)，這種開發(fā)流程更多地被當做是比較獨立的一次開發(fā)流程，與之對應的則是需要協(xié)調和管理的長期功能開發(fā)分支。

另外還需注意到，在此例中Git不會對git branch -d命令發(fā)出警告，因為new-feature的內容已經合并到主分支里了。

在某些情況下，雖然目標分支的提交歷史相對于當前分支是線性的，可以進行快進合并，但你仍然希望有一個合并commit來標志合并在此commit發(fā)生過，那么可以在執(zhí)行git merge命令時使用--no-ff選項。

git merge --no-ff 

以上命令將指定分支合并到當前分支，但總會生成一個合并commit（即便這一合并操作可以快進）。當你需要在倉庫的提交歷史中標記合并事件時這一命令相當有用。

三路合并

接下來的例子與上面比較像，但是因為main分支在feature分支向前發(fā)展的過程中，自身也發(fā)生的改變，因此在合并時需要進行三路合并。在進行大的功能開發(fā)或者有多個開發(fā)者同時進行開發(fā)時這種場景相當常見。

Start a new feature
git checkout -b new-feature main
# Edit some files
git add 
git commit -m "Start a feature"
# Edit some files
git add 
git commit -m "Finish a feature"
# Develop the main branch
git checkout main
# Edit some files
git add 
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

需注意在這種情況下，由于沒有辦法直接把main的頂端指針移動到new-feature分支上，因此Git無法執(zhí)行快進合并。

在大多數(shù)實際工作場景中，new-feature應該是一個很大的功能，開發(fā)過程持續(xù)了相當長的時間，這也就難免同時期在main分支上也有新的提交。如果你的功能分支大小像上面的例子一樣小，則完全可以使用rebase將new-feature分支變基到main分支上，然后再執(zhí)行一次快進合并。這樣也會避免在項目提交歷史中產生過多的冗余。

解決沖突

如果將要合并的兩個分支都修改了同一個而文件的同一個部分內容，Git就無法確定應該使用哪個版本的內容。當這種情況發(fā)生時，合并過程會停止在合并commit提交之前，以便給用戶留下機會手動修復這些沖突。

在Git的合并過程中，很棒的一點是它使用人們熟知的 編輯 / 暫存 / 提交 這樣的工作流程來解決沖突。當碰到合并沖突時，執(zhí)行git status命令會列出哪些文件含有沖突并需要手動解決。比如說當兩個分支都修改了hello.py文件的同一部分，你會看到類似下面這樣的信息：

On branch main
Unmerged paths:
(use "git add/rm ..." as appropriate to mark resolution)
both modified: hello.py

沖突是如何顯示的

當Git在合并過程中碰到了沖突，它會編輯受影響的文件中的相關內容，并添加視覺標記用以展示沖突中雙方在此部分的不同內容。這些視覺標記為：<<<<<<<,=======,>>>>>>>。要找到沖突發(fā)生的具體位置，在文件中搜索這些視覺標記會非常便捷地達成目的。

here is some content not affected by the conflict
<<<<<<< main
this is conflicted text from main
=======
this is conflicted text from feature branch
>>>>>>> feature branch;

通常來說在 ====== 標記之前的內容來自于接收合并的分支，而在這之后的內容來自于要合并的分支。

一旦找到沖突的部分，就可以根據(jù)需要來修正沖突。當你完成了沖突的修復并準備好繼續(xù)進行合并，只需要執(zhí)行git add命令把已經解決好沖突的文件添加暫存區(qū)，告訴Git這些沖突已經解決完畢即可。這之后就像正常提交代碼一樣執(zhí)行git commit完成合并commit。這個過程跟正常情況下提交代碼是完全一樣的，也就是說對于普通開發(fā)者來說處理沖突也是小菜一碟。

還需注意合并沖突只可能出現(xiàn)在三路合并過程中，在快進合并中不會出現(xiàn)沖突。

關于“Git的merge命令實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，小編每天都會為大家更新不同的知識點。