前言

從2019年上半年云音樂(lè)的客戶端團(tuán)隊(duì)開(kāi)始遷移到雙周迭代后懦趋，隨之而來(lái)的是我們需要重新調(diào)整代碼分支的管理方法击你，來(lái)應(yīng)對(duì)開(kāi)發(fā)流程的變更偏形。

雙周迭代顧名思義一周開(kāi)發(fā)一周測(cè)試但指，目的就是為了快速交付寡痰。縱觀整個(gè)開(kāi)發(fā)流程棋凳，我們需要在兩周內(nèi)完成：需求交互評(píng)審-技術(shù)方案設(shè)計(jì)-開(kāi)發(fā)測(cè)試-CodeReview-持續(xù)集成-灰度全量發(fā)布等工作拦坠，并且把每個(gè)節(jié)點(diǎn)的時(shí)間都固定下來(lái)，節(jié)奏感對(duì)于開(kāi)發(fā)來(lái)說(shuō)特別重要剩岳，讓大家明確每個(gè)時(shí)間點(diǎn)應(yīng)該做什么贞滨，對(duì)于簡(jiǎn)化管理和提高效率尤為重要。那新的代碼分支管理如何適應(yīng)這種節(jié)奏呢拍棕？

先談?wù)劕F(xiàn)狀

業(yè)內(nèi)有很多的分支管理方法晓铆，包括著名的GitFlow，TBD以及從他們衍生出來(lái)的版本绰播。

GitFlow

GitFlow設(shè)計(jì)非常全面骄噪，考慮到了實(shí)際開(kāi)發(fā)過(guò)程中的各種問(wèn)題，都能穩(wěn)定應(yīng)對(duì)幅垮，是非常適合大型項(xiàng)目的代碼管理腰池。他的主要理念包括2個(gè)主干分支：Master和Develop，1個(gè)發(fā)布分支：Release忙芒，若干個(gè)開(kāi)發(fā)分支：Feature示弓，以及HotFix分支。整體實(shí)施流程略微復(fù)雜呵萨，對(duì)持續(xù)集成不太友好奏属，下面是典型的GitFlow模型：

GitFlow有幾個(gè)問(wèn)題：

因?yàn)榇蠹叶荚谧约旱腇eature分支上面開(kāi)發(fā)，特別是對(duì)于長(zhǎng)期的Feature分支會(huì)可能存在嚴(yán)重的合并沖突問(wèn)題潮峦，需要花費(fèi)大量的時(shí)間解決

同樣是基于第一條囱皿，導(dǎo)致Feature分支之間相互隔離勇婴，以至于CI/CD困難，單個(gè)功能可能沒(méi)有問(wèn)題嘱腥，但合并以后是否也沒(méi)問(wèn)題誰(shuí)也無(wú)法保證

TBD

Trunk Based Development早在svn時(shí)代就已經(jīng)流行耕渴，是種比較簡(jiǎn)單的分支管理模型，他只有一個(gè)主干分支齿兔，每個(gè)人寫完代碼自測(cè)通過(guò)后就往主干上面Push橱脸，要發(fā)布的時(shí)候就拉個(gè)Release分支，對(duì)持續(xù)集成友好分苇。他主要的幾個(gè)問(wèn)題：

如果臨上線前發(fā)現(xiàn)有問(wèn)題添诉，剔除代碼比較困難

即使沒(méi)有需求變更要下掉代碼，有些提交如果未能達(dá)到上線標(biāo)準(zhǔn)医寿，需要加Feature Toggle來(lái)控制打開(kāi)關(guān)閉栏赴。這是一個(gè)需要平衡的事情，往往會(huì)增加一定開(kāi)發(fā)成本和風(fēng)險(xiǎn)靖秩。

Aone Flow

這是一篇阿里技術(shù)的博客里面提到的他們內(nèi)部采用的代碼管理方式须眷，區(qū)別于GitFlow，核心點(diǎn)在于沒(méi)有固定Develop分支盆偿，要發(fā)布的時(shí)候把要上線的Feature分支一起合并到一個(gè)Release分支柒爸，這樣做的好處是需求變更哪個(gè)Feature不要了，只需要把其他Feature分支重新合并到新的Release分支即可

云音樂(lè)代碼分支管理

那云音樂(lè)需要怎么樣的代碼分支管理方法事扭？我們適應(yīng)目前雙周迭代的分支管理模型應(yīng)該要滿足這幾點(diǎn)：

夠敏捷但又管理可控

云音樂(lè)迭代了這些年后版本相對(duì)趨于穩(wěn)定，對(duì)于一個(gè)千萬(wàn)級(jí)體量的中大型APP來(lái)說(shuō)乐横，穩(wěn)定求橄，風(fēng)險(xiǎn)可控是一個(gè)基本訴求。而在這前提下面如何保持一定的靈活度是需要一直探索和尋找的平衡點(diǎn)

雙周迭代的重要特性通俗來(lái)講就是“上下車”制度葡公，或者叫趕班車罐农，也即能靈活應(yīng)對(duì)突發(fā)情況隨時(shí)將一個(gè)需求挪到下個(gè)版本上線，或者將一個(gè)需求挪到這個(gè)版本上線催什，這就意味著Release分支的合入也需要非常靈活涵亏，這一點(diǎn)跟Aone Flow非常像。

流程穩(wěn)定蒲凶，認(rèn)知清晰

所有開(kāi)發(fā)同學(xué)都非常清晰雙周迭代的節(jié)奏气筋，也要非常清晰代碼管理的方法，每個(gè)迭代周期往哪個(gè)上線分支合并旋圆，什么節(jié)點(diǎn)合入都是非常明確的宠默。避免出現(xiàn)忘記合入不知道往哪里合入的問(wèn)題，同時(shí)我們也希望把這部分合并工作能夠分?jǐn)偟矫總€(gè)開(kāi)發(fā)灵巧，做到自己分支自己負(fù)責(zé)搀矫。

CodeReview是必需的

相信大家都能認(rèn)可CodeReview的意義抹沪，最佳做CodeReview的時(shí)機(jī)往往是代碼合入點(diǎn)，通過(guò)PR或者M(jìn)R來(lái)發(fā)起

4. 方便持續(xù)集成流水線

傳統(tǒng)方式因?yàn)榇蠹叶继峤辉谧约悍种厦嫒壳颍a分散同時(shí)存在合并后產(chǎn)生額外風(fēng)險(xiǎn)融欧，我們期望盡可能盡快把Feature分支集合起來(lái)走流水線

那為了解決這幾個(gè)問(wèn)題，我們需要幾個(gè)分支：

穩(wěn)定的發(fā)布分支卦羡，統(tǒng)一大家認(rèn)知確保在固定合入時(shí)機(jī)點(diǎn)前發(fā)起MR進(jìn)行合入蹬癌，我們固定叫release-xxxx分支，在下個(gè)迭代開(kāi)始時(shí)從前一個(gè)Release分支拉出

穩(wěn)定的主干分支（Master）虹茶，只是作為HotFix分支拉取逝薪，當(dāng)然其實(shí)HotFix也可以從已發(fā)布的Release分支或者Tag里面拉出，Master的意義在于確保一條可以隨時(shí)發(fā)布的干凈的版本記錄

若干開(kāi)發(fā)分支蝴罪，這個(gè)Feature分支和GitFlow董济，AoneFlow沒(méi)有差別，在合入Release分支的時(shí)候進(jìn)行CodeReview要门，我們固定叫feature-xxx

HotFix分支虏肾，這個(gè)沒(méi)有差別

所以整體來(lái)看我們的最佳實(shí)踐會(huì)是GitFlow和AoneFlow的結(jié)合體：

1. 首先是把GitFlow的Develop和Release分支進(jìn)行合并，減少?gòu)?fù)雜度欢搜。固定每個(gè)迭代的Release分支名字方便認(rèn)知封豪，對(duì)于客戶端來(lái)說(shuō)Release沒(méi)有環(huán)境之分，不需要有多個(gè)Release分支

2.? 不允許在Release上面提交代碼炒瘟，所有功能開(kāi)發(fā)都走Feature分支吹埠，即便合并后有bugfix，仍然走Feature修改再次合入疮装，這樣確保所有代碼合入都是測(cè)試完成且CodeReview完成缘琅。同時(shí)也具備AoneFlow的優(yōu)點(diǎn)，一旦需求有要下車廓推，則直接刪掉Release分支進(jìn)行重建刷袍，把其他Feature分支合入即可。

3.? 因?yàn)楣潭ê先霑r(shí)間節(jié)點(diǎn)樊展，所以持續(xù)集成的時(shí)間也是固定的呻纹，我們一般是定在第二周的周二，雖然沒(méi)有第一時(shí)間像TBD一樣進(jìn)行专缠，但已經(jīng)是我們想要找到的一個(gè)合理平衡點(diǎn)雷酪。當(dāng)然Feature分支上面也可以有流水線，跑的東西略微有些差別（Feature分支跑的東西偏測(cè)試環(huán)境）

4. Master分支隨時(shí)處于Release狀態(tài)藤肢，確保HotFix能夠及時(shí)進(jìn)行

其他

除了約定太闺，云音樂(lè)內(nèi)部還有個(gè)叫《全鏈路研發(fā)平臺(tái)》的工具來(lái)輔助代碼分支管理，這個(gè)平臺(tái)涵蓋了從需求產(chǎn)生到交付的全生命周期管理嘁圈，包括需求排期省骂，提測(cè)蟀淮，打包，持續(xù)集成钞澳，卡點(diǎn)怠惶，發(fā)布等環(huán)節(jié)。和代碼分支管理相關(guān)的主要有這些：

每個(gè)需求都會(huì)要求關(guān)聯(lián)一個(gè)Feature分支轧粟，否則無(wú)法提測(cè)

每個(gè)Feature分支是否合入當(dāng)前迭代固定的Release分支狀態(tài)可查詢策治，方便管理版本上線前卡點(diǎn)

最后，沒(méi)有一個(gè)代碼分支管理方法是直接適用自己的項(xiàng)目場(chǎng)景的兰吟，還是要根據(jù)實(shí)際情況進(jìn)行一些取舍通惫，找到一個(gè)最佳的平衡點(diǎn)。

更多文章請(qǐng)關(guān)注微信公眾號(hào)：安卓之美