前言

沒有最好的代碼管理方式，只有最適合當(dāng)前需求的方式。

正文

移動(dòng)項(xiàng)目中，有用SVN做代碼管理，也有用Git。從效率上來(lái)講，Git會(huì)比SVN更優(yōu)：最直接的是SVN在切換分支時(shí)比較慢。
為了適應(yīng)敏捷開發(fā)的快速迭代，代碼管理工具大體都在慢慢切向Git。
本文是介紹項(xiàng)目中用Git管理代碼分支遇到的問題。

項(xiàng)目初期

用Git管理代碼，首先要區(qū)分分支，最直接的做法是僅提供兩個(gè)分支：
為了保持開發(fā)階段的便利，提供develop分支，作為日常開發(fā)的提交分支；
為了保證外網(wǎng)代碼的可查，提供master分支，作為日常發(fā)布的打包分支；
當(dāng)版本發(fā)布之后，還需要打tag記錄對(duì)應(yīng)版本，比如說release_1.0.0.10。（版本號(hào)通常為3位，第四位是build號(hào)，用于蘋果審核時(shí)對(duì)同版本的不同二進(jìn)制版本做一個(gè)區(qū)分）

隨著版本迭代，有兩個(gè)新的訴求出現(xiàn)：
1、code review，每個(gè)版本的新增代碼要經(jīng)過review再發(fā)布，以控制版本質(zhì)量；
2、版本灰度的需要，并且可能會(huì)有一灰、二灰、三灰等多次灰度；

最初使用的是cherry-pick功能，在develop分支的代碼以需求作為維度，當(dāng)某個(gè)需求做完（QA驗(yàn)收通過）之后，就可以通過cherry-pick的方式將代碼提到一個(gè)master的分支，再走merge request的方式合入master，此時(shí)reviewer可以review本次提交的代碼并同意合入分支。

這樣好處是可以僅保留兩個(gè)分支，需求的開發(fā)、測(cè)試和驗(yàn)收都在develop分支，灰度的bugfix都在master分支進(jìn)行。在項(xiàng)目早期測(cè)試和驗(yàn)收人力非常寶貴的情況下，同一條分支驗(yàn)收可以兼顧多個(gè)需求，較大程度提高驗(yàn)收效率；而且初期參與寫代碼的研發(fā)就寥寥數(shù)人，統(tǒng)一分支開發(fā)也是方便研發(fā)同時(shí)對(duì)多個(gè)需求同時(shí)進(jìn)行開發(fā)和問題修復(fù)，最大程度利用研發(fā)人力。

項(xiàng)目穩(wěn)定

隨著項(xiàng)目逐漸復(fù)雜和穩(wěn)定下來(lái)，開始暴露一些問題：每個(gè)版本的需求往往是到版本末期才合入，導(dǎo)致develop分支在后期cherry-pick的時(shí)候容易產(chǎn)生沖突，因?yàn)槟硞€(gè)類在版本后期可能有多個(gè)人修改；同時(shí)版本末期的review時(shí)間也比較少，此時(shí)集中的多個(gè)merge request會(huì)造成review的困難；對(duì)QA來(lái)說，合碼沖突中造成的Bug非常不可控，因?yàn)樵撔枨笠呀?jīng)驗(yàn)收完畢，結(jié)果合碼產(chǎn)生了新的Bug，導(dǎo)致回歸測(cè)試的時(shí)間變長(zhǎng)。

各方要求：

• RD訴求：
  開發(fā)階段，可以自由提交代碼；
  代碼合并階段，功能可以拆分review；
  驗(yàn)收階段，修改可以方便同步給QA和UI；
  灰度階段，所有代碼需要走M(jìn)R；

• QA訴求：
  測(cè)試階段，bug修復(fù)要及時(shí)且不要被其他需求影響；
  回歸階段，回歸核心功能和當(dāng)前版本變動(dòng)點(diǎn)；
  發(fā)版階段，只需要過checklist；

• UI/DA/UE/PM訴求：
  驗(yàn)收階段：方便驗(yàn)收，條件簡(jiǎn)單；
  回歸階段：提前發(fā)現(xiàn)需求沖突的問題；

綜合多方述求，從產(chǎn)品質(zhì)量和研發(fā)效率角度出發(fā)，兼顧質(zhì)量穩(wěn)定和業(yè)務(wù)迭代效率，保留需求的開發(fā)、測(cè)試、驗(yàn)收流程比較便捷，切換到多分支的管理模式。

多分支管理

一句話概括：關(guān)閉develop和master分支的push功能，保留merge request能力階段采用拉分支，各個(gè)需求單獨(dú)分支開發(fā)，測(cè)試驗(yàn)收通過之后再合入develop。

需求開發(fā)階段：每個(gè)人拉出需求分支，分支內(nèi)任意提交；
測(cè)試驗(yàn)收階段：需求分支驗(yàn)收需求，必要的單獨(dú)配置測(cè)試環(huán)境；
代碼合并階段：分支上的代碼提merge到develop分支；
灰度階段：只允許合入bug修復(fù)，其他延后下個(gè)版本；
提審階段：最后一個(gè)灰度的代碼進(jìn)行打包提交，添加tag；

合碼規(guī)范

提交類型

• feature--需求類型，分支名以feature_需求名作為開頭；
• bugfix-具體bug，分支名以bugfix_具體bug作為開頭；

沖突解決
分支在提merge request的時(shí)候會(huì)發(fā)生沖突，此時(shí)需要解決沖突：
1、以feature_test_merge為例，先拉下來(lái)feature_test_merge分支；
2、在分支feature_test_merge拉取目標(biāo)分支的代碼，這里以master為例：

找到?jīng)_突的文件，解決完沖突將文件標(biāo)記為已解決，最后提交合并解決沖突；

如果可以，盡量使用rebase；因?yàn)閞ebase完之后，分支的提交會(huì)更加清晰，否則git提交記錄處可能會(huì)有很多條線。

總結(jié)

不管是developer分支集中開發(fā)再cherry-pick到beta分支，還是多分支管理的模式都有各自的優(yōu)缺點(diǎn)，只能說在項(xiàng)目合適的時(shí)期選用適當(dāng)?shù)姆绞健?br> 代碼的分支管理會(huì)隨著項(xiàng)目迭代不斷進(jìn)行優(yōu)化，總體來(lái)說是往兩個(gè)方向發(fā)展：保證版本的質(zhì)量，以及提高開發(fā)的效率。

在修改這篇文章的時(shí)候頗有感觸，文章提到的項(xiàng)目初期真的是很早以前的事情了。
隨著項(xiàng)目逐漸發(fā)展，分支管理已經(jīng)逐漸習(xí)以為常，現(xiàn)在大家關(guān)注的都是組件化多倉(cāng)管理和多倉(cāng)合碼，pipeline包大小檢測(cè)、安全檢測(cè)、覆蓋率檢測(cè)、單元測(cè)試等等。