衝突的產生

很多命令都可能出現衝突，但從根本上來講，都是merge 和 patch（應用補丁）時產生衝突。而rebase就是重新設定基準，然後應用補丁的過程，所以也會衝突。git pull會自動merge，repo sync會自動rebase，所以git pull和repo sync也會產生衝突。當然git rebase就更不用說了。

衝突的型別

邏輯衝突

git自動處理（合併/應用補丁）成功，但是邏輯上是有問題的。比如另外一個人修改了檔名，但我還使用老的檔名，這種情況下自動處理是能成功的，但實際上是有問題的。又比如，函式返回值含義變化，但我還使用老的含義，這種情況自動處理成功，但可能隱藏著重大BUG。這種問題，主要通過自動化測試來保障。所以最好是能夠寫出比較完備的自動化測試用例。這種衝突的解決，就是做一次BUG修正。不是真正解決git報告的衝突。

內容衝突

兩個使用者修改了同一個檔案的同一塊區域，git會報告內容衝突。我們常見的都是這種，後面的解決辦法也主要針對這種衝突。

內容衝突的解決辦法

發現衝突

一般來講，出現衝突時都會有“CONFLICT”字樣：
$ git pull
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.但是，也有例外，repo sync的報錯，可能並不是直接提示衝突，而是下面這樣：error: project mini/sample注：無論是否存在衝突，只要本地修改不是基於伺服器最新的，它都可能報告這個錯誤，解決方法都是一樣。這個時候，需要進入報錯的專案（git庫）目錄，然後執行git rebase解決：git rebase remote-branch-name

衝突解決的一般過程

merge/patch的衝突解決

先編輯衝突，然後git commit提交。注：對於git來講，編輯衝突跟平時的修改程式碼沒什麼差異。修改完成後，都是要把修改新增到快取，然後commit。

rebase的衝突解決

rebase的衝突解決過程，就是解決每個應用補丁衝突的過程。解決完一個補丁應用的衝突後，執行下面命令標記衝突已解決（也就是把修改內容加入快取）：git add -u注：-u 表示把所有已track的檔案的新的修改加入快取，但不加入新的檔案。然後執行下面命令繼續rebase：git rebase --continue有衝突繼續解決，重複這這些步驟，直到rebase完成。如果中間遇到某個補丁不需要應用，可以用下面命令忽略：git rebase --skip如果想回到rebase執行之前的狀態，可以執行：git rebase --abort注：rebase之後，不需要執行commit，也不存在新的修改需要提交，都是git自動完成。

編輯衝突的方法

直接編輯衝突檔案

衝突產生後，檔案系統中衝突了的檔案（這裡是test.txt）裡面的內容會顯示為類似下面這樣：a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c其中：衝突標記<<<<<<< （7個<）與=======之間的內容是我的修改，=======與>>>>>>>之間的內容是別人的修改。此時，還沒有任何其它垃圾檔案產生。最簡單的編輯衝突的辦法，就是直接編輯衝突了的檔案（test.txt），把衝突標記刪掉，把衝突解決正確。