前言

從2019年上半年云音樂的客戶端團隊開始遷移到雙周迭代后，隨之而來的是我們需要重新調整代碼分支的管理方法，來應對開發流程的變更。

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

先談談現狀

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

GitFlow

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

GitFlow有幾個問題：

因為大家都在自己的Feature分支上面開發，特別是對于長期的Feature分支會可能存在嚴重的合并沖突問題，需要花費大量的時間解決

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

TBD

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

如果臨上線前發現有問題，剔除代碼比較困難

即使沒有需求變更要下掉代碼，有些提交如果未能達到上線標準，需要加Feature Toggle來控制打開關閉。這是一個需要平衡的事情，往往會增加一定開發成本和風險。

Aone Flow

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

云音樂代碼分支管理

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

夠敏捷但又管理可控

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

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

流程穩定，認知清晰

所有開發同學都非常清晰雙周迭代的節奏，也要非常清晰代碼管理的方法，每個迭代周期往哪個上線分支合并，什么節點合入都是非常明確的。避免出現忘記合入不知道往哪里合入的問題，同時我們也希望把這部分合并工作能夠分攤到每個開發，做到自己分支自己負責。

CodeReview是必需的

相信大家都能認可CodeReview的意義，最佳做CodeReview的時機往往是代碼合入點，通過PR或者MR來發起

4. 方便持續集成流水線

傳統方式因為大家都提交在自己分支上面，代碼分散同時存在合并后產生額外風險，我們期望盡可能盡快把Feature分支集合起來走流水線

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

穩定的發布分支，統一大家認知確保在固定合入時機點前發起MR進行合入，我們固定叫release-xxxx分支，在下個迭代開始時從前一個Release分支拉出

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

若干開發分支，這個Feature分支和GitFlow，AoneFlow沒有差別，在合入Release分支的時候進行CodeReview，我們固定叫feature-xxx

HotFix分支，這個沒有差別

所以整體來看我們的最佳實踐會是GitFlow和AoneFlow的結合體：

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

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

3. 因為固定合入時間節點，所以持續集成的時間也是固定的，我們一般是定在第二周的周二，雖然沒有第一時間像TBD一樣進行，但已經是我們想要找到的一個合理平衡點。當然Feature分支上面也可以有流水線，跑的東西略微有些差別(Feature分支跑的東西偏測試環境)

4. Master分支隨時處于Release狀態，確保HotFix能夠及時進行

其他

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

每個需求都會要求關聯一個Feature分支，否則無法提測

每個Feature分支是否合入當前迭代固定的Release分支狀態可查詢，方便管理版本上線前卡點

最后，沒有一個代碼分支管理方法是直接適用自己的項目場景的，還是要根據實際情況進行一些取舍，找到一個最佳的平衡點。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。