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