? ? ? android項目有很多小團隊，基于省事，在版本控制上很多都是簡單粗暴，常常就是一個開發團隊只有一個主干分支在同時進行開發、發版、修改bug工作，省事是省事，卻也埋下一些隱患，假如線上版本出了一個緊急bug，而你正在進行新功能開發，怎么辦？ 把代碼備份回退先修改bug? 還是新拉個分支進行修改? 有什么策略？怎么控制代碼質量？
下面我介紹一下我在我們團隊實施的版本控制方法。
總體而言是基于git-flow的流程原則，即：
1、主干分支（master）永遠可用
主干分支即線上版本的代碼分支，必須保證絕對穩定可靠可用，新開分支是在主干分支基礎上。
2、開發分支（develop）平時使用
在開發新功能或修改不太緊急的bug時都在開發分支上進行修改提交
3、緊急情況開臨時分支
線上版本出現緊急bug，需要快速修復發版，在主干分支基礎上開臨時分支進行修復bug
4、臨時增加一個小型功能開特性分支
產品經理應老板的要求，在短時間內需要上線一個新功能，那么可以在主干基礎上開一個特性分支進行此功能的開發。
因基于保證主干分支穩定可靠的原則上，在其他分支寫完代碼后進行合并，可以使用pull request功能進行輔助迭代流程，使用pull request有以下好處：
1、組內成員可以互相進行代碼review,發現代碼風格或邏輯錯誤
2、配合jenkins的Merge驗證，能減少因合并帶來的代碼風險。
下面我以gitlab為例，介紹具體流程如下：
在開發分支或其他臨時分支開發完畢，在gitlab中發起pull request
發起完 pull request之后，組內成員都能看到這個pull request,
對這個pull request可以進行代碼review（組內成員互相進行）,可以針對任意一行代碼進行交流改進，并能提示此代碼作者，以此來規范代碼和提高代碼質量，你們交流的信息都會在gitlab上留下記錄，其他同事打開也能愉快的參與到討論中來。
在檢查完代碼邏輯沒有問題的情況下，準備合并到主干（線上）分支前，jenkins會幫助分析合入之后是否會產生錯誤
如圖,發起pull request后，jenkins會自動觸發工作，進行模擬代碼合并，并進行打包及單元測試工作，同時向gitlab發起消息，告知是否成功，如果檢測通過，可以在gitlab放心點擊“Aceept Merge Request”，此段代碼即會成功合入主干分支（免去以前還需要在本地進行合并測試再提交步驟）。
通過分支控制，及jenkins的對merge的預檢測，整個流程下來，基本能很好的覆蓋移動開發場景。
關于jenkins如何進行合入(pull request)預檢測，以及如何利用jenkins進行版本發布，請看如下兩篇：
