版本分支管理標準 - Trunk Based Development 主幹開發模型

以前分享過《版本分支管理標準 - Git Flow》，不過在實際使用過程當中， 由於其有必定的複雜度，使用起來較爲繁瑣，因此一些人員較少的團隊並不會使用這個方案。

在這基礎上，一些新的分支管理標準被提出。這裏轉發一下這個標準：《Trunk Based Development 主幹開發模型》。

---

Preface

在以前的博文中咱們介紹了 Git Flow 分支模型，正如文中所說，Git Flow 偏向於控制管理，使用了較多的分支，流程頗爲複雜。大量的團隊在實踐過程當中也遇到了頗多問題，其中大部分來自長期存在的分支。隨着軟件開發模型的演進，GitHub Flow、Trunk Based Development 等模型也應運而生，也已被 Google、Facebook、TW 等企業實踐。本文主要介紹 TBD 模型。

Git Flow的問題

• 合併衝突，合併衝突在使用 Git Flow 是很是常見的。緣由很簡單：若是你有多個並行功能分支，他們長時間存在，那麼極可能代碼庫的相同部分在兩個功能分支中被分別更改。合併衝突不只對於須要手動解決的開發人員來講是使人沮喪的，也增長了在代碼中破壞某些功能的風險，由於當你不得不決定使用哪一個版本代碼時，很容易犯錯。
• 功能分離，在合併到同一個分支以前，你不能測試兩個功能的組合。當你在單獨的分支中開發幾天甚至幾周的功能時，當合並回主分支後，可能也會發生兩個功能的相互做用影響了你的代碼。
• 並無作到持續交付，在 Git Flow 分支模型下，發佈是很是有計劃的，一個 feature 必需要通過一系列步驟才能到達生產環境，在時間上平均一個 feature 都要等待 兩週時間才能長線，這樣的等待並不是是需求上的「按計劃發佈」，而是從技術上就形成了發佈瓶頸，顯然難以達到持續交付的要求。
• 與持續集成相悖，你會發現，在堅持持續集成實踐的狀況下，feature 分支是一件很是矛盾的事情。持續集成鼓勵更加頻繁的代碼集成和交互，讓衝突越早解決越好。feature 分支的代碼隔離策略卻在儘量推遲代碼的集成。

GitHub Flow

GitHub Flow 是一個更輕量級的軟件開發模型，示意圖以下。它摒棄了 Git Flow 中繁雜的分支， 只保留一個主分支 master 。開發新功能時從 master 分支上拉取 feature 分支，開發完成後發起 Pull-Request ，小組內進行評審和反饋，此時也進行 Code Review 。測試經過後合併回主分支。

相比於 Git Flow，這種方式由於省去了一些分支而下降了複雜度，同時也更符合持續集成的思想，以一張故事卡爲集成的最小單位，相對來講集成的週期短，反饋的速度也快，可以及早的遇到問題並及早解決。

順着持續集成的思想，若是咱們把 GitHub Flow 分支模型作得再極致一點，咱們不要 feature 分支，或者把 feature 分支只留在本地；不須要使用 Pull-Request 而是直接 Push 到遠程 master 分支，咱們就作到了 Trunk based Development。

TBD

Trunk based Development，又叫 主幹開發 ，是一套代碼分支管理策略，開發人員之間經過約定向被指定爲 主幹 的分支提交代碼，以此抵抗由於長期存在的多分支致使的開發壓力。此舉可 避免分支合併的困擾，保證隨時擁有可發佈的版本 。「主幹」這個詞隱喻了樹木生長的場景，樹木最粗最長的部位是主幹，分支從主幹分離出來可是長度有限。

使用主幹開發後，咱們的代碼庫原則上就只能有一個 Trunk 分支即 master 分支了，全部新功能的提交也都提交到 master 分支上，保證每次提交後 master 分支都是可隨時發佈的狀態。沒有了分支的代碼隔離，測試和解決衝突都變得簡單，持續集成也變得穩定了許多，但也有以下幾個問題：

• 如何避免發佈引入未完成 Feature，答案是使用 Feature Toggle 。在代碼庫里加一個特性開關來隨時打開和關閉新特性是最容易想到的也是最容易被質疑的解決方案。Feature Toggle 是有成本的，不論是在加 Toggle 時的代碼設計，仍是在移除 Toggle 時的人力成本和風險，都是須要和它帶來的價值進行衡量的。
• 如何進行線上 Bug Fix，答案是在發佈時打上 Release Tag，一旦發現這個版本有問題，若是此時 master 分支尚未其餘提交，那能夠直接在 master 分支上 Hot Fix 而後合併至 release 分支；若是 master 分支已經有了提交就須要作如下三件事：
  • 從 Release Tag 建立發佈分支。
  • 在 master 上作 Fix Bug 提交。
  • 將 Fix Bug 提交 Cherry Pick 到 release 分支。
  • 爲 release 分支打上新的 Tag 並作一次發佈。

說明

• 主幹開發是助力實現 持續集成 和 持續交付 的關鍵因素。開發團隊的成員一天屢次地將代碼提交到主幹分支，知足了持續交付的必要條件。團隊的工做在 24 小時內就能夠被整合，這保證了代碼版本隨時處於可發佈狀態，使得持續交付成爲可能。
• 你能夠選擇直接向主幹分支提交代碼的方式（適用於小團隊）或者採用 Pull-Request 的方式，只要保證特性分支不能長期存在，而且產品是獨立存在的。
• 根據團隊規模和提交頻率， 特性分支可用於合併到主幹分支前的代碼審查和持續集成 。這些特性分支可讓開發人員在代碼合併到主幹分支以前進行持續審查，而對於較小規模的團隊，則能夠直接向主幹分支提交。
• 根據預期的發佈頻率，你的團隊或許須要實時從主幹分支建立 發佈分支 以確保發佈版本不會有新的提交，這些分支應該在發佈完成後一段時間內刪除。另外一方面，你的團隊也能夠選擇從主幹分支發佈而不須要發佈分支，並採用「 修復前進（fix forward） 」的策略進行 bug fix，這種發佈策略適用於高吞吐量的團隊（high-throughput teams）。

References

• TBD中文官網
• 分支模型與主幹開發

以上所述就是小編給你們介紹的《Trunk Based Development 主幹開發模型》，但願對你們有所幫助，若是你們有任何疑問請給我留言，小編會及時回覆你們的。在此也很是感謝你們對 碼農網 的支持！