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進行版本釋出，請看如下兩篇：