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

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

    上兩章分別講了 1.提交歸併請求。 2.檢視程式碼並解決衝突。這一章講 最後一個步驟 3.確認歸併請求

上一章我們講了提交程式碼歸併請求遇到衝突的情況。也講解了如何解決衝突。在解決完衝突之後，重新提交程式碼，再提一個歸併請求，在沒有衝突的情況下就可以順利進行確認歸併請求，並進行歸併了。

      不過在本章，需要另外講解一個概念：角色

       我們知道，git是進行團隊合作進行程式碼歸併的工具，那麼，不同的使用者，一定是會有不同的許可權和功能的。

        上幾章講的都是建立自己的賬號，然後建立分支，然後提交程式碼，然後進行程式碼歸併。而實際使用過程中，很可能建立賬戶的人擁有賬號的所有許可權，然後部分人擁有不同分支的不同許可權，只有擁有該分支的使用者，才會允許其他分支往該分支提交的歸併請求。也就是對本分支擁有許可權的人，或者指定的人，才能對往本分支提交的歸併請求進行確認，從而將其他分支的提交過來的程式碼歸併請求的程式碼歸併到本分支中。而大部分人，是隻有拉取分支，寫完程式碼，提交到自己分支上，然後提交歸併請求到整合分支上，然後由上級進行程式碼歸併到整合分支上，而提交的人，是沒有許可權進行程式碼歸併確認 並 確認歸併請求的。

        那麼，確認並歸併請求的前提是，對當前分支擁有歸併許可權。

        由於本文舉例使用的使用者是對整個專案擁有許可權的，所以也就有歸併所有分支的許可權。而實際工作過程中，作為普通的開發者是用不到這部分功能的，只有核心開發人員，例如有評審程式碼許可權的人， 才會對別的開發提交的歸併請求，進行合併。

        說了這麼多，我們應該站在整個專案的高度瞭解建立開源專案的過程，所以，雖然這部分功能工作中即便用不到，也建議您學習一下，說不定就會在某個時刻用的到了。

       上一章已經解決程式碼衝突了，  這一章講解如何檢視歸併請求的時候，使用github頁面解決衝突的歸併請求。

      先上github，發現兩個分支有衝突。

此處仍然建立歸併請求

點選右上角的 解決衝突按鈕

我們看到衝突內容，

<<<<<<< test
        //提交程式碼測試，與主分支衝突的程式碼
=======
        //修改master分支
>>>>>>> master

是master分支有提交過對註釋內容修改。然後test分支未拉取最新的程式碼，也更新了這一行註釋，然後提交歸併請求的時候，就造成了master分支上的改變，test分支並不知曉，所以這行程式碼就衝突了。

解決衝突很簡單，就是看下，這兩行程式碼，哪行是需要的。比如，我們這次提交，需要保留的是test分支的註釋，那麼就直接去掉master分支的註釋即可。如果，兩者都是需要的，那麼就把兩者合併為需要的內容之後，再提交程式碼到test，然後再建立歸併請求，就不會衝突了。當然，可有可能是需要保留master分支的程式碼，捨棄，test分支的改變的 。具體怎麼合併，必須是對兩個分支程式碼清晰明瞭其作用的前提下才能合併的。否則，雖然解決了衝突，很可能不是最終需要的結果，那這次解決衝突就是錯誤的。

解決衝突後，進入下面的頁面，重新提交歸併請求

跳轉到歸併請求頁面

點選歸併請求

成功歸併請求

後面的delete branch 會刪除test分支，就是提交過來的歸併請求的分支。如果不需要了這個分支，可以刪除掉。如果還需要在上面進行程式碼修改，就不要delete branch。

     實際工作中，一般提交到此分支的歸併請求不是自己，而是其他人，這種情況下，最好不要刪除別人的分支，讓提交人自己刪除自己分支就好。因為本文後續還要使用test分支，所以我這裡不刪除分支。

      此時，test分支的程式碼已經完全提交到master分支上了。

不過實際過程中，可能會有很多的程式碼衝突，這種情況下，可能頁面解決衝突會很麻煩，這種情況下，可以使用ide開發工具機型程式碼歸併。

下一章講解  如何使用eclipse進行兩個有衝突的分支的程式碼衝突解決。