之前分享過《版本分支管理標准 - 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
以上所述就是小編給大家介紹的《Trunk Based Development 主干開發模型》，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對 碼農網 的支持！