前言

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

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

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

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

GitFlow

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

GitFlow有幾個(gè)問題：

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

同樣是基于第一條，導(dǎo)致Feature分支之間相互隔離，以至于CI/CD困難，單個(gè)功能可能沒有問題，但合并以后是否也沒問題誰也無法保證

TBD

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

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

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

Aone Flow

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

云音樂代碼分支管理

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

夠敏捷但又管理可控

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

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

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

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

CodeReview是必需的

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

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

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

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

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

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

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

HotFix分支，這個(gè)沒有差別

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

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

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

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

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

其他

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的svn合并分支到主干_谈谈代码分支管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。