馬蜂窩的前端火了！遇到衝突不怕懟，強制提交就是幹

「 前言 」

相信你們都在世界盃期間有意無心地看到過馬蜂窩的洗腦廣告，短短的15秒，品牌名就出現了6次。「旅遊以前，爲何要先上馬蜂窩」，這些不斷重複的廣告詞讓人猶如魔咒般印象深入。

有不瞭解的小夥伴能夠上他們家的官網大概看下，馬蜂窩，一家從事旅遊行業的新銳互聯網公司。

背景鋪墊完畢以後，讓咱們進入今天的正題。

「 正文 」

最近馬蜂窩移動端的某個線上頁面出現了明顯的BUG，截圖在某技術社區瘋傳，獻上頁面截圖供你們瞻仰一下：

前端圈裏的潛規則就是，好事不出門，好玩事兒傳千里。瞬間馬蜂窩的前端在碼農圈子裏火了，愛湊熱鬧的程序猿們紛紛留言：

馬蜂窩的前端老哥666，能跑起來也是牛逼

遇到衝突不怕懟，強制提交就是幹！！！

請問貴公司還缺前端嗎？我就喜歡這樣自由任性的開發氛圍～

人生不如意之事十之八九，合併分支每每也不是一路順風的

我寫的代碼不會有問題！報錯根本不影響頁面功能！ie 用戶根本不用管！瑪德，被開除了…

這要是擱我司，還不得被技術經理diss，一口鹽汽水噴死我都是極有可能的！

領導的腦殼嗡嗡嗡...

......

其實仔細想一想，發生在馬蜂窩身上的這種bug在咱們開發環境中很常見，並不稀奇。只要是在前端團隊裏呆過的碼農都知道，這不就是提交代碼合併分支發現衝突了，然而並無解決就直接發佈了麼。

首先要想清楚一個問題，在相似馬蜂窩的前端團隊中，爲何git提交代碼會出現衝突？

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

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

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

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

=======以後，>>>>>>>以前是要merge過來的另外一條分支上的代碼。

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

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

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

「 git解決代碼提交衝突 」

如今大部分一線互聯網公司都是採用git做爲公司內部版本迭代的工具，它能夠敏捷高效地處理任何或小或大的項目，天然在前端團隊平常協做開發的過程，出現代碼提交衝突就很常見了，這也是不少剛入行的前端新人小白們在工做中常常會碰到的比較棘手的問題。

代碼提交衝突通常分爲兩種，樹衝突和內容衝突。

文件名修改形成的衝突，稱爲樹衝突。

好比，A同事把文件更名爲A.C，B同事把同一個文件更名爲B.C，那麼B同事將這兩個commit合併時，會產生衝突。
若是最終肯定用B同事的文件名，那麼解決辦法以下：

git rm A.C
 
git rm origin-name.C
 
git add B.C
 
git commit

若是最終肯定用A同事的文件名，那麼解決辦法以下：

git rm B.C
 
git rm origin-name.C
 
git add A.C
 
git commit

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

通常來說，出現衝突時都會有「conflict」字樣，特別的直接報錯repo sync的報錯，可能並非直接提示衝突。

如今，須要進入報錯的項目（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自動完成。

直接編輯衝突文件：

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

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

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

此時，尚未任何其它垃圾文件產生。

總結一下：

當Git沒法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。

解決衝突就是把Git合併失敗的文件手動編輯爲咱們但願的內容，再提交。

用git log --graph命令能夠看到分支合併圖。

「 前端協做流程 」

下面來講說我對前端協做流程的一點理解。

項目的可維護性第一。咱們並非一我的在作事，項目的維護和二次開發多是直接或間接的團隊合做。好的可維護性能夠從四個方面得到:

• 代碼的鬆藕合，高度模塊化，將頁面內的元素視爲一個個模塊，相互獨立，儘可能避免耦合太高的代碼，從HTML，CSS，JavaScript三個層面考慮模塊化。
• 良好的註釋。
• 注意代碼的彈性，在性能和彈性的選擇上，通常狀況下以彈性爲優先考慮條件，在保證彈性的基礎上，適當優化性能。
• 嚴格按照規範編寫代碼。

「 如何避免提交衝突 」

不少童鞋都把git看成我的代碼備份工具，沒有涉及多人提交代碼到中央版本庫。可是在多人使用時，不能簡單地再延續原來我的使用時的習慣。如何提交才能避免版本衝突呢？

首先在本地 clone 項目源碼回來以後，只有一個默認分支master，不要直接在上面工做。

a.創建一個本身的分支，如取名working： git branch working
b.切換到這個新分支： git checkout working
c.如今能夠自由修改代碼並保存了。

2.確保你修改的代碼都是本身負責項目下，或者說你的兩次提交之間，沒有其餘人來改相同項目下的代碼，若是不能避免，你就要在下面的merge步驟手工處理衝突了。

3.提交代碼時按下面的步驟：(能夠將下面的腳本保存在你的每一個項目之下，每次只修改提交一個項目)

git checkout working    --force  #確保使用的是工做分支<br>
git add .<br>
git commit -m"$1" -a     #提交代碼到本地，工做分支增長一個版本，這裏的$1是運行腳本的第一個參數
 
git checkout master      <br>
git pull origin master   #切換回默認分支，並將默認分支和中央最新版本合併<br>
git merge working        #在本地合併你的此次修改到默認分支<br>
git push origin master   #提交到中央版本庫，接下來仍是要切換回工做分支的<br>
git checkout working   --force&emsp;

若是不當心動了生產環境（就是隻從中央版本庫pull到本地）的文件，只好將本地版本退回一個，再從中央代碼庫pull代碼合併。

git reset --hard HEAD

因此說，在平時的前端開發工做中，養成一個良好的有規範的git提交代碼的習慣，是多麼的重要

「 結尾 」

不過，這個bug事故在發生以後，被馬蜂窩的前端人員迅速解決掉了，可見其對bug復現的處理能力，同時對馬蜂窩制定測試流程規範的測試工程師致敬！

若是能讓我對馬蜂窩的前端er說一句話，我只想問一句：

貴公司還缺測試嗎？

---

更多文章我會第一時間更新在公衆號<閏土大叔>裏面，歡迎關注~