目錄

引言

開始Merge

1、History視圖

2、Team菜單

3、Git Repositories視圖

巧用Git Staging視圖

放棄Merging

可能的Merge結(jié)果

---

引言

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

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

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

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

開始Merge

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

1、History視圖

2、Team菜單

3、Git Repositories視圖

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

巧用Git Staging視圖

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

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視圖可以為我們準(zhǔn)確聚焦需要我們集中注意力解決沖突的文件上，而不是由我們自己去搜索全部的資源文件。

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

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

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

放棄Merging

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

通常，當(dāng)我們配置merge選項(xiàng)的時(shí)候都會選擇如下單選框：

這并不是一個(gè)常規(guī)意義上的單選框，因?yàn)榈谌?xiàng)完全可以和前兩項(xiàng)同時(shí)存在。當(dāng)選擇第三項(xiàng)的時(shí)候，發(fā)生沖突后，會立刻終止merge操作，而不是將沖突文件標(biāo)記成<<<<<<======>>>>>>>的一個(gè)文件。這樣，我們就可以試探性的去進(jìn)行merge操作，而不是一發(fā)生沖突，就立刻要去合并。

但如果我們?nèi)匀贿x擇上圖所示的默認(rèn)配置，當(dāng)發(fā)生沖突后，我們?nèi)绾尾拍芡顺鰉erging工作，或者暫時(shí)先不去完成沖突修改的合并工作呢？

這里有一個(gè)reset功能，了解一下：

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

打開Team > Reset...

默認(rèn)Hard選項(xiàng)即可，點(diǎn)擊Reset按鈕：

再次確認(rèn)回退：

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

這樣，我們呆一會再來進(jìn)行merge操作的時(shí)候就不會有任何問題了。

可能的Merge結(jié)果

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

下面是三種情況的merge結(jié)果會話框：

注意！！！Already-up-to-date代表兩個(gè)分支的提交已經(jīng)同步，而不是內(nèi)容已經(jīng)沒有沖突！

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

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

可就在這時(shí)，我們突然想起來剛剛有一個(gè)方法沒有merge進(jìn)來，當(dāng)我們再去merge這兩個(gè)分支時(shí)，就會出現(xiàn)Already-up-to-date的結(jié)果，它代表兩個(gè)分支的提交版本已經(jīng)是同步了。

所以這點(diǎn)要格外注意，在merging的時(shí)候要盡可能的確保已經(jīng)完成了所有修改的合并。因?yàn)橐坏┨峤?#xff0c;Git將不再會認(rèn)為這兩個(gè)分支是有沖突的了。

?

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

參考：《EGit/User Guide》

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。