之前分享過《版本分支管理標(biāo)準(zhǔn) - Git Flow》，不過在實(shí)際使用過程中， 因?yàn)槠溆幸欢ǖ膹?fù)雜度，使用起來較為繁瑣，所以一些人員較少的團(tuán)隊(duì)并不會(huì)使用這個(gè)方案。

在這基礎(chǔ)上，一些新的分支管理標(biāo)準(zhǔn)被提出。這里轉(zhuǎn)發(fā)一下這個(gè)標(biāo)準(zhǔn)：《Trunk Based Development 主干開發(fā)模型》。

---

Preface

在之前的博文中我們介紹了 Git Flow 分支模型，正如文中所說，Git Flow 偏向于控制管理，使用了較多的分支，流程頗為復(fù)雜。大量的團(tuán)隊(duì)在實(shí)踐過程中也遇到了頗多問題，其中大部分來自長(zhǎng)期存在的分支。隨著軟件開發(fā)模型的演進(jìn)，GitHub Flow、Trunk Based Development 等模型也應(yīng)運(yùn)而生，也已被 Google、Facebook、TW 等企業(yè)實(shí)踐。本文主要介紹 TBD 模型。

Git Flow的問題

• 合并沖突，合并沖突在使用 Git Flow 是非常常見的。原因很簡(jiǎn)單：如果你有多個(gè)并行功能分支，他們長(zhǎng)時(shí)間存在，那么很可能代碼庫的相同部分在兩個(gè)功能分支中被分別更改。合并沖突不僅對(duì)于需要手動(dòng)解決的開發(fā)人員來說是令人沮喪的，也增加了在代碼中破壞某些功能的風(fēng)險(xiǎn)，因?yàn)楫?dāng)你不得不決定使用哪個(gè)版本代碼時(shí)，很容易犯錯(cuò)。
• 功能分離，在合并到同一個(gè)分支之前，你不能測(cè)試兩個(gè)功能的組合。當(dāng)你在單獨(dú)的分支中開發(fā)幾天甚至幾周的功能時(shí)，當(dāng)合并回主分支后，可能也會(huì)發(fā)生兩個(gè)功能的相互作用影響了你的代碼。
• 并沒有做到持續(xù)交付，在 Git Flow 分支模型下，發(fā)布是非常有計(jì)劃的，一個(gè) feature 必須要經(jīng)過一系列步驟才能到達(dá)生產(chǎn)環(huán)境，在時(shí)間上平均一個(gè) feature 都要等待 兩周時(shí)間才能長(zhǎng)線，這樣的等待并非是需求上的“按計(jì)劃發(fā)布”，而是從技術(shù)上就造成了發(fā)布瓶頸，顯然難以達(dá)到持續(xù)交付的要求。
• 與持續(xù)集成相悖，你會(huì)發(fā)現(xiàn)，在堅(jiān)持持續(xù)集成實(shí)踐的情況下，feature 分支是一件非常矛盾的事情。持續(xù)集成鼓勵(lì)更加頻繁的代碼集成和交互，讓沖突越早解決越好。feature 分支的代碼隔離策略卻在盡可能推遲代碼的集成。

GitHub Flow

GitHub Flow 是一個(gè)更輕量級(jí)的軟件開發(fā)模型，示意圖如下。它摒棄了 Git Flow 中繁雜的分支， 只保留一個(gè)主分支 master 。開發(fā)新功能時(shí)從 master 分支上拉取 feature 分支，開發(fā)完成后發(fā)起 Pull-Request ，小組內(nèi)進(jìn)行評(píng)審和反饋，此時(shí)也進(jìn)行 Code Review 。測(cè)試通過后合并回主分支。

相比于 Git Flow，這種方式因?yàn)槭∪チ艘恍┓种Ф档土藦?fù)雜度，同時(shí)也更符合持續(xù)集成的思想，以一張故事卡為集成的最小單位，相對(duì)來說集成的周期短，反饋的速度也快，能夠及早的遇到問題并及早解決。

順著持續(xù)集成的思想，如果我們把 GitHub Flow 分支模型做得再極致一點(diǎn)，我們不要 feature 分支，或者把 feature 分支只留在本地；不需要使用 Pull-Request 而是直接 Push 到遠(yuǎn)程 master 分支，我們就做到了 Trunk based Development。

TBD

Trunk based Development，又叫 主干開發(fā) ，是一套代碼分支管理策略，開發(fā)人員之間通過約定向被指定為 主干 的分支提交代碼，以此抵抗因?yàn)殚L(zhǎng)期存在的多分支導(dǎo)致的開發(fā)壓力。此舉可 避免分支合并的困擾，保證隨時(shí)擁有可發(fā)布的版本 。“主干”這個(gè)詞隱喻了樹木生長(zhǎng)的場(chǎng)景，樹木最粗最長(zhǎng)的部位是主干，分支從主干分離出來但是長(zhǎng)度有限。

使用主干開發(fā)后，我們的代碼庫原則上就只能有一個(gè) Trunk 分支即 master 分支了，所有新功能的提交也都提交到 master 分支上，保證每次提交后 master 分支都是可隨時(shí)發(fā)布的狀態(tài)。沒有了分支的代碼隔離，測(cè)試和解決沖突都變得簡(jiǎn)單，持續(xù)集成也變得穩(wěn)定了許多，但也有如下幾個(gè)問題：

• 如何避免發(fā)布引入未完成 Feature，答案是使用 Feature Toggle 。在代碼庫里加一個(gè)特性開關(guān)來隨時(shí)打開和關(guān)閉新特性是最容易想到的也是最容易被質(zhì)疑的解決方案。Feature Toggle 是有成本的，不管是在加 Toggle 時(shí)的代碼設(shè)計(jì)，還是在移除 Toggle 時(shí)的人力成本和風(fēng)險(xiǎn)，都是需要和它帶來的價(jià)值進(jìn)行衡量的。
• 如何進(jìn)行線上 Bug Fix，答案是在發(fā)布時(shí)打上 Release Tag，一旦發(fā)現(xiàn)這個(gè)版本有問題，如果此時(shí) master 分支還沒有其他提交，那可以直接在 master 分支上 Hot Fix 然后合并至 release 分支；如果 master 分支已經(jīng)有了提交就需要做以下三件事：
  • 從 Release Tag 創(chuàng)建發(fā)布分支。
  • 在 master 上做 Fix Bug 提交。
  • 將 Fix Bug 提交 Cherry Pick 到 release 分支。
  • 為 release 分支打上新的 Tag 并做一次發(fā)布。

說明

• 主干開發(fā)是助力實(shí)現(xiàn) 持續(xù)集成 和 持續(xù)交付 的關(guān)鍵因素。開發(fā)團(tuán)隊(duì)的成員一天多次地將代碼提交到主干分支，滿足了持續(xù)交付的必要條件。團(tuán)隊(duì)的工作在 24 小時(shí)內(nèi)就可以被整合，這保證了代碼版本隨時(shí)處于可發(fā)布狀態(tài)，使得持續(xù)交付成為可能。
• 你可以選擇直接向主干分支提交代碼的方式（適用于小團(tuán)隊(duì)）或者采用 Pull-Request 的方式，只要保證特性分支不能長(zhǎng)期存在，并且產(chǎn)品是獨(dú)立存在的。
• 根據(jù)團(tuán)隊(duì)規(guī)模和提交頻率， 特性分支可用于合并到主干分支前的代碼審查和持續(xù)集成 。這些特性分支可以讓開發(fā)人員在代碼合并到主干分支之前進(jìn)行持續(xù)審查，而對(duì)于較小規(guī)模的團(tuán)隊(duì)，則可以直接向主干分支提交。
• 根據(jù)預(yù)期的發(fā)布頻率，你的團(tuán)隊(duì)或許需要實(shí)時(shí)從主干分支創(chuàng)建 發(fā)布分支 以確保發(fā)布版本不會(huì)有新的提交，這些分支應(yīng)該在發(fā)布完成后一段時(shí)間內(nèi)刪除。另一方面，你的團(tuán)隊(duì)也可以選擇從主干分支發(fā)布而不需要發(fā)布分支，并采用“ 修復(fù)前進(jìn)（fix forward） ”的策略進(jìn)行 bug fix，這種發(fā)布策略適用于高吞吐量的團(tuán)隊(duì)（high-throughput teams）。

References

• TBD中文官網(wǎng)
• 分支模型與主干開發(fā)

以上所述就是小編給大家介紹的《Trunk Based Development 主干開發(fā)模型》，希望對(duì)大家有所幫助，如果大家有任何疑問請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì) 碼農(nóng)網(wǎng) 的支持！

轉(zhuǎn)載于:https://www.cnblogs.com/zgynhqf/p/10862446.html

總結(jié)

以上是生活随笔為你收集整理的版本分支管理标准 - Trunk Based Development 主干开发模型的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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