當兩條分支對同一個檔案的同一個文字塊進行了不同的修改，並試圖合併時，Git不能自動合併的，稱之為衝突(conflict)。解決衝突需要人工處理。

那麼讓我來帶領大家解讀下上面截圖中馬蜂窩出現的bug事故分析：

<<<<<<<標記衝突開始，後面跟的是當前分支中的內容。

HEAD指向當前分支末梢的提交。

=======之後，>>>>>>>之前是要merge過來的另一條分支上的程式碼。

>>>>>>>之後的dev是該分支的名字。

對於簡單的合併，手工編輯，然後去掉這些標記，最後像往常的提交一樣先add再commit即可。

這其中就涉及到了公司前端團隊協作開發的流程問題，以及git解決程式碼衝突的實際問題，讓我們以馬蜂窩的bug事故為引子，來繼續深入聊聊團隊協作的那些事兒。

「 git解決程式碼提交衝突 」

現在大部分一線網際網路公司都是採用git作為公司內部版本迭代的工具，它可以敏捷高效地處理任何或小或大的專案，自然在前端團隊日常協作開發的過程，出現程式碼提交衝突就很常見了，這也是很多剛入行的前端新人小白們在工作中經常會碰到的比較棘手的問題。

程式碼提交衝突一般分為兩種，樹衝突和內容衝突。

檔名修改造成的衝突，稱為樹衝突。

比如，A同事把檔案改名為A.C，B同事把同一個檔案改名為B.C，那麼B同事將這兩個commit合併時，會產生衝突。

如果最終確定用B同事的檔名，那麼解決辦法如下：

1git rm A.C
2
3git rm origin-name.C
4
5git add B.C
6
7git commit

如果最終確定用A同事的檔名，那麼解決辦法如下：

1git rm B.C
2
3git rm origin-name.C
4
5git add A.C
6
7git commit

內容衝突（git pull拉取最新程式碼發現）

一般來講，出現衝突時都會有“conflict”字樣，特別的直接報錯repo sync的報錯，可能並不是直接提示衝突。

現在，需要進入報錯的專案（git庫）目錄，然後執行git rebase解決：

1git rebase remote -branch-name

衝突解決的一般步驟

1merge/patch的衝突解決

先編輯衝突，然後git commit提交。

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

1rebase的衝突解決

rebase的衝突解決過程，就是解決每個應用補丁衝突的過程。

解決完一個補丁應用的衝突後，執行下面命令標記衝突已解決（也就是把修改內容加入快取）

1git add -u      // -u 表示把所有已track的檔案的新的修改加入快取，但不加入新的檔案

然後執行下面命令繼續rebase：

1git rebase --continue

有衝突繼續解決，重複這這些步驟，直到rebase完成。

如果中間遇到某個補丁不需要應用，可以用下面命令忽略：

1git rebase --skip

如果想回到rebase執行之前的狀態，可以執行：

1git rebase --abort

注：rebase之後，不需要執行commit，也不存在新的修改需要提交，都是git自動完成。

直接編輯衝突檔案：

衝突標記<<<<<<< （7個<）與=======之間的內容是我的修改

=======與>>>>>>>之間的內容是別人的修改

最簡單的編輯衝突的辦法，就是直接編輯衝突了的檔案（test.txt），把衝突標記刪掉，把衝突解決正確。

此時，還沒有任何其它垃圾檔案產生。