目錄

引言

開始Merge

1、History視圖

2、Team菜單

3、Git Repositories視圖

巧用Git Staging視圖

放棄Merging

可能的Merge結果

---

引言

Git鼓勵開發者使用分支來進行程序的開發。但是最終只會有一個版本發行出去，因此，我們需要將開發好的分支merge（即合并，以下統稱merge）到我們的主分支上。

前面的文章《Git初學札記（四）————Git Push的常規操作與Pull沖突解決》中已經簡單的提到過merge的操作，但是，Git的merge功能并不局限于此。（比如，當其他開發者格式化了代碼，這個時候我們又該如何merge？這里就涉及到了Git的高級merge功能。不過博主還沒有找到EGit的相關設置）

在Git中合并是相當容易的。Git使得多次合并另一個分支變得很容易，這意味著我們可以有一個始終保持最新的長期分支。經常解決小的沖突，比在一系列提交后解決一個大的沖突要好。

在發生比較棘手的沖突時，Git并不會嘗試智能地自動解決它，Git的哲學是聰明的決定無歧義的合并方案。

開始Merge

如何開始merge工作呢？EGit為我們提供了三個可以觸發merge工作的入口：

1、History視圖

2、Team菜單

3、Git Repositories視圖

這三個視圖中都有merge操作的入口，不論哪種方式，Git都是認為將其他分支merge到當前分支上。所以在merge之前，請先切換到主線分支上（注意主線分支并不代表master分支，這是相對而言的，主線分支可以是任何分支，例如有兩個分支 A 和 B，如果要將B merge 到 A 上，那么A就是主線分支，B就是支線分支）。

巧用Git Staging視圖

EGit的Git Staging視圖不僅只是在add index 和commit 時才會用到，當發生merge沖突時也會有大用處。

EGit的官方文檔這樣寫道：

A merge can result in conflicts which require user action. This is the case when the content of files cannot be merged automatically. These conflicts are marked with a label decoration in the Staging View. Using the Staging View to find the files with conflicts in order to resolve them is handy since the Staging View shows only modified files so that you don't have to wade through all of your resources but only those which might need your attention for resolving the conflicts.

Staging視圖可以為我們準確聚焦需要我們集中注意力解決沖突的文件上，而不是由我們自己去搜索全部的資源文件。

在這里，我們可以右鍵沖突文件，選擇我們希望的merging操作：

我們可以直接打開文件，看到<<<<<<<======>>>>>>>標記之后的文件內容（如下圖），手動去修改。

也可以通過Merge Tool中提供的一些工具來進行merge操作，或者干脆雙擊文件，EGit會直接打開文件比對視圖。

放棄Merging

當然，如果我們養成良好的習慣，經常merge小的改變，我們也不會苦了自己。但是，如果我們遇到了很多沖突修改需要merge 卻沒有足夠的時間完成這些合并工作，我們該如何退出這次merge操作？

通常，當我們配置merge選項的時候都會選擇如下單選框：

這并不是一個常規意義上的單選框，因為第三項完全可以和前兩項同時存在。當選擇第三項的時候，發生沖突后，會立刻終止merge操作，而不是將沖突文件標記成<<<<<<======>>>>>>>的一個文件。這樣，我們就可以試探性的去進行merge操作，而不是一發生沖突，就立刻要去合并。

但如果我們仍然選擇上圖所示的默認配置，當發生沖突后，我們如何才能退出merging工作，或者暫時先不去完成沖突修改的合并工作呢？

這里有一個reset功能，了解一下：

當我們看到了如下圖所示的一系列沖突文件而頭大想去休息一下的時候，為了防止誤操作，我們希望先退出合并編輯，一會再集中精力來解決它怎么辦？

打開Team > Reset...

默認Hard選項即可，點擊Reset按鈕：

再次確認回退：

這樣，我們就回退到了還沒有點擊merge按鈕的樣子：

這樣，我們呆一會再來進行merge操作的時候就不會有任何問題了。

可能的Merge結果

merge可大致分為三種情況：Already-up-to-date ，Fast-forward ，Conflicting?

下面是三種情況的merge結果會話框：

注意！！！Already-up-to-date代表兩個分支的提交已經同步，而不是內容已經沒有沖突！

如何解釋這句話？假設，我們將B分支merge?到A上的時候發生了沖突。這個時候Git會將沖突內容全部寫入當前分支的沖突文件中，用<<<<<=====>>>>>標記出來，并且要求使用者完成編輯操作。

這個時候我們已經進入了一種“merging”的狀態，Git默認使用者此刻正在解決沖突。是的，它是這么認為的，然而，不論我們有沒有認真修改沖突文件中的內容，也不論有沒有真正意義上的完成了兩個文件的修改整合工作，在我們點擊commit之后，Git即默認我們已經完成了merge工作，Git就會將兩個分支的指針指向同一個commit，并且將當前的主線分支標記為Merged。

可就在這時，我們突然想起來剛剛有一個方法沒有merge進來，當我們再去merge這兩個分支時，就會出現Already-up-to-date的結果，它代表兩個分支的提交版本已經是同步了。

所以這點要格外注意，在merging的時候要盡可能的確保已經完成了所有修改的合并。因為一旦提交，Git將不再會認為這兩個分支是有沖突的了。

?

綜上，就是關于EGit在merge的時候涉及到的一些常規操作和一些基本視圖。如有疑問，歡迎文末留言。

參考：《EGit/User Guide》

?

總結

以上是生活随笔為你收集整理的Git初学札记（七）————合并分支（merge）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。