上一章講到 將遠端程式碼庫中的自己分支上的程式碼，歸併到主分支中，主要分為三個大的步驟：

    1.提交歸併請求 2.檢視程式碼，解決衝突  3.確認歸併請求

上一章講了 1.提交歸併請求。 這一章主要講第二個步驟 ：2.檢視程式碼並解決衝突。下一章講3.確認歸併請求

首先，講解導致 “衝突” 的根源。如果只有test一個分支，往master 上歸併請求，而master 分支上並沒有提交過相同的部分的程式碼。那麼，這隻會是一次正常的歸併，這樣的一次歸併，並不會導致衝突。這種情況，直接檢視程式碼，（無程式碼衝突，確認是正確的需要進行歸併到master中的程式碼），那麼直接確認歸併請求，完成一次程式碼歸併就好了。

現在我們考慮兩種可能出現程式碼衝突的情況。1.master分支上的 Fibonacci.java中的第38行有修改，然後有人拉取的就是master分支，然後程式碼也提到master 分支上。此時當我們test分支上也修改了Fibonacci.java中的第38行，此時，當我們歸併的時候，會發現，master主分支和test分支都改了同一行程式碼，到底保留哪一行呢？github是無法進行判斷的。於是，丟擲 "衝突” ，並不進行自動合併，讓提交的人進行程式碼合併解決完衝突之後，再重新提交程式碼合併請求。2.第二種和第一種情況的本質是一樣的，只不過，程式碼的來源不同，可能是兩個分支都往master分支上歸併程式碼，而兩個分支同時修改了一個檔案的同一行。解決方法也是一樣的。首先拒絕自動歸併。等待解決衝突之後，master分支再接收程式碼歸併。

為了講解方便起見，以第一種出現衝突的情況進行講解。

注：（如果想要檢視如何歸併第二種出現衝突的問題，請結合第四章，拉取新分支，並在新分支上修改一個檔案的某一行，然後再在test分支上修改同一個檔案的同一行。人為造成兩個分支程式碼的衝突，然後分別將各個分支的程式碼提交到各自的github遠端程式碼庫的相應分支上。然後，將兩個分支提交歸併，依次歸併兩個分支程式碼，看看，是可以先歸併一個請求，還是兩個請求都不能歸併。）

一。首先，我們人為造成一次衝突

1.我們當前分支是在test分支上，直接修改Fibonacci.java的第38行，並提交到test分支。（具體操作參考第四章）

2.現在先本地myeclipse的分支切換到master分支上，修改Fibonacci.java的第38行。

我這裡遇到了一個問題，就是切換分支之後，報錯了。原因是，前幾次歸併過程式碼，遠端程式碼倉庫，test分支上程式碼合併到master分支了。然後通過pull動作，下載的到本地的時候，衝突了。因為本地現在主要修改的是test分支。而master分支才是主要標準的程式碼。所以我把本地test分支的修改過的程式碼提交到遠端倉庫的test分支。然後重新下載了master分支和test分支。

具體如何下載專案，還是參考第三章。這裡補充一點，下載程式碼的時候，會提示下載那個分支，兩個分支都選擇就好了。

現在假定已經切換到master分支了。

然後修改38行，為了不影響程式碼，這裡只是加行註釋。 

提交程式碼到master分支。（參考第四章，相信你已經會了。 ）

然後我們到github遠端倉庫（https://github.com/ 登陸）看下，兩個分支，各自的修改。

先進入專案（老奶年的講解方式，有點囉嗦） 

然後選擇分支，先看master分支，後面test分支一樣的看法，可以開兩個網頁看。當然也可以使用github網站提供的程式碼比對功能進行對比著看。這裡兩個分開來看。

按照專案的結構，找到修改檔案，點選檔名，進入程式碼。

程式碼如下：找到38行，看到我們的修改

然後看test分支的修改：

 這說明，已經修改了同一個檔案的同一行程式碼了。

然後。將test分支往master分支合併。

 具體提交一次歸併請求的方式，參考第六章。

建立請求的過程中，出現衝突提示：

程式碼不能自動合併。但不用擔心，你仍然可以建立pull請求。

此時，怎麼處理呢？這裡最好的方式，是回頭修改程式碼。修改master分支還是test分支呢？一般情況下，大家都會以master分支作為主幹分支，大家程式碼都提交到master分支上。所以，最好的方式，就是先儲存好test分支該處的修改到本地。然後pull下master分支的修改，覆蓋test分支。然後基於master的最新的改動修改test分支。

我們這裡，繼續建立歸併請求，看下github網站是怎麼進行處理的。

建立一次歸併請求

額，只能關閉該次請求了。

既然要管理該次請求，為何還要在這費盡口舌呢。

這是因為，剛才我們是通過自己提交程式碼，知道這次請求是有衝突的。然後我們可能會自己不去提交merge （歸併）請求。但實際的使用環境中，很有可能，提交歸併（merge pull request）請求的人與通過歸併請求的人不是同一個人（會是擁有不同操作許可權的賬戶）。只有負責master分支的人，才可以允許其他的歸併請求合併。其他分支的程式碼的人，只有提交歸併請求的許可權。正常情況下，會強制大家在出現衝突的時候，先自己解決衝突後再提交。但實際過程中，可能有人誤操作，即便有衝突沒解決就提交歸併請求了。這種情況下就關閉該次歸併請求就好了。

當test分支的賬戶的歸併請求被拒絕之後，首先問master分支的賬戶，為什麼拒絕歸併。

此時得知，衝突，就回到自己的程式碼分支本地，解決衝突。

回到myeclipse ，切換到test分支，然後pull程式碼 

點merge 合併程式碼。此時會把有衝突的部分都列出來。然後把不要的刪掉。因為我們這裡的衝突少，而且容易解決。像有一些複雜的衝突，比如同時修改的部分，有相同的程式碼行。那麼可能一個方法出現好多衝突點，非常不好解決。建議，手動解決衝突，最好不要使用merge解決。

解決完衝突後，再重新提交歸併。然後就是一次正常的歸併請求了。不再老奶奶一樣囉嗦了。

下一章講確認歸併請求。