為什么我從 Git Flow 開發(fā)模式切換到了 Trunk Based 開發(fā)模式？

我已經(jīng)使用 Git Flow 構(gòu)建我的 Git 分支有幾年了。但是，我遇到了 Git Flow 的一些問題，其中大部分來自長期存在的分支。解決這些問題的方案就是 Trunk Based Development。這是一個(gè)非常簡單的技術(shù)，也是有效的持續(xù)交付的基礎(chǔ)。在這篇文章中，我會(huì)告訴你我是如何通過 HolidayCheck 的 IOS 開發(fā)團(tuán)隊(duì)從 Git Flow 過度到 Trunk Based Development 的開發(fā)的。您將了解最重要的步驟，以及從 Trunk Based Development 中獲得的好處，請繼續(xù)閱讀。

Git Flow 的問題

合并沖突

合并沖突在使用 Git Flow 是非常常見。原因很簡單：如果你有多個(gè)并行功能分支，他們長時(shí)間存在，那么很可能在代碼庫的相同部分在兩個(gè)不同的分支中被更改。合并沖突不僅對于需要手動(dòng)解決的開發(fā)人員來說是令人沮喪的。這也增加了在代碼中破壞某些功能的風(fēng)險(xiǎn)，因?yàn)楫?dāng)你不得不決定使用哪個(gè)版本代碼時(shí)，很容易犯錯(cuò)。即使你把一個(gè)分支合并到另一個(gè)分支時(shí)你做的都是正確的，可能也會(huì)發(fā)生這兩個(gè)特性的組合影響了你的代碼。

構(gòu)建

功能分離

在合并到一個(gè)分支之前，你是不能測試兩個(gè)功能的組合。當(dāng)你在單獨(dú)的分支機(jī)構(gòu)中開發(fā)幾天甚至幾周的功能時(shí)，由于兩個(gè)功能的相互作用而產(chǎn)生的問題發(fā)生了。當(dāng)你對這些問題反映遲緩時(shí)，你可能不得不改變你為新功能編寫的代碼的更多部分。這意味著你已經(jīng)浪費(fèi)了很多的時(shí)間來創(chuàng)建你不再需要的代碼。

許多不同的功能分支也可能會(huì)讓你的軟件的手動(dòng)測試人員感到困惑。他們總是必須知道在哪個(gè)臨時(shí)環(huán)境中可以找到新功能。不同的階段環(huán)境通常也意味著不同的構(gòu)建任務(wù)，用于監(jiān)控任務(wù)的不同屏幕等。

不可預(yù)測的發(fā)布

Git Flow 還有另一個(gè)問題，這是以上兩點(diǎn)的結(jié)果：如果功能分支尚未合并，則不可能知道需要多少時(shí)間才能發(fā)布。你不知道它是因?yàn)槟悴恢滥膫€(gè)合并會(huì)發(fā)生沖突，你也不知道新功能將如何相互影響。不能在任何時(shí)候發(fā)布將使你缺乏信心。

解決方案

Trunk Based Development

好消息！上述所有問題都有解決方案，就是Trunk Based Development。你只有一個(gè)主分支，即主干（Master 或者 Mainline）。不再有開發(fā)分支，也沒有存在時(shí)間很久的分支。所有的提交都會(huì)盡快合并到主干中，至少每天一次。通過如此迅速的合并到主干，合并沖突變的非常罕見。使用短時(shí)間分支是避免合并沖突的4個(gè)簡單技巧之一。即使你遇到了合并沖突，也可能很容易解決，因?yàn)閺纳洗魏喜⒌街鞲珊笞兓⒉荒敲创?。不同功能之間的干擾立即可見，可以在功能正在進(jìn)行時(shí)測試。

基于主干的開發(fā)也將鼓勵(lì)你的團(tuán)隊(duì)以小的 Step 思考和工作，從而做到小的提交，這些提交可以快速合并到主干。通常，小 Step 可以減少錯(cuò)誤數(shù)量，并有助于創(chuàng)建模塊化設(shè)計(jì)。

最大的問題時(shí)：如果每天將代碼推送到一個(gè)不穩(wěn)定的主干，即使某個(gè)功能還沒有完成，你如何才能避免出現(xiàn)有問題的主干？請接著閱讀來尋找答案。

如何從 Git Flow 到 Trunk Based Development 功能切換

功能切換

當(dāng)我在 HolidayCheck 向我的團(tuán)隊(duì)介紹 Trunk Based Development 的開發(fā)時(shí)，為了能夠迅速的將代碼提交到主干，有一個(gè)第一步是絕對必要的！在開始我們的分支結(jié)構(gòu)之前，我們必須確保我們使用能夠盡快的融入開發(fā)分支的并且存在時(shí)間很短的分支。解決辦法相當(dāng)簡單，我們開始使用功能切換——源碼中的一些開關(guān)決定功能是否處于活動(dòng)狀態(tài)。

只要功能沒有準(zhǔn)備好被發(fā)布，它就會(huì)被禁用。這使我們可以在不破壞任何東西的情況下將其推入到開發(fā)分支。開發(fā)人員和手動(dòng)測試人員可以在一些設(shè)置中啟用對于普通用戶隱藏的每個(gè)功能。開發(fā)分支隨時(shí)準(zhǔn)備被發(fā)布，因?yàn)槲赐瓿傻墓δ軐⒈魂P(guān)閉。他們將被推送到客戶，但是是不可見狀態(tài)的。一旦某個(gè)功能完成，他就會(huì)打開并在下一個(gè)版本中可用。

當(dāng)我們在代碼中切換這些功能時(shí)，我們意識(shí)到它們不僅在功能開發(fā)的時(shí)候有用！即使功能完成，在代碼中保持切換也是非常好的。如果我們有可能為所有用戶遠(yuǎn)程控制切換，那么只要我們發(fā)現(xiàn)他對我們的轉(zhuǎn)化率或其他關(guān)鍵數(shù)字有不良影響，我們就可以快速停用該功能。此外，如果發(fā)生任何錯(cuò)誤或者服務(wù)器的流量負(fù)載過高，我們總是能夠立即關(guān)閉該功能。這一點(diǎn)尤其重要，因?yàn)槲覀儽仨毜却嗵?，直到蘋果回顧，出了我們的 IOS 應(yīng)用程序的新版本。能夠在沒有新版本的情況下禁用功能是一個(gè)非常強(qiáng)大的武器。

現(xiàn)在，隨著所有功能的切換，我們還可以做另一件偉大的事情：A/B 測試！由于每個(gè)功能都可以隨著遠(yuǎn)程控制，所以我們可以只為部分用戶群啟用某項(xiàng)功能，并禁用其他功能。這樣做，我們可以看到一個(gè)功能真正的執(zhí)行。我們可以在小測試組上測試新功能，然后決定是否應(yīng)該為每個(gè)人啟用它，或者如果我們看到負(fù)面影響將其刪除。我們使用 Optimizely 來控制和評估我們的 A/B 測試，但也有其他工具可用。

一個(gè)分支約定所有

現(xiàn)在我們可以快速地將我們的功能分支合并到開發(fā)分支中（因?yàn)槲赐瓿傻墓δ芤呀?jīng)停用），我們可以隨時(shí)發(fā)布開發(fā)分支。問題是：我們是否還需要一個(gè)開發(fā)和一個(gè)主分支？答案是：不需要。我們可以直接把所有東西都交給 Master 而不是 Develop 分支。Master 隨時(shí)準(zhǔn)備投入生產(chǎn)（不要忘記每當(dāng)有東西被推入 Master 時(shí)，都要運(yùn)行所有的測試）。如果我們想創(chuàng)建一個(gè)發(fā)行版本，我們可以直接從主分支創(chuàng)建，或者為此創(chuàng)建一個(gè)發(fā)行版分支。最新發(fā)布的提交標(biāo)有 Git tag。所以引入功能切換后的第二步是刪除開發(fā)分支！在這里，我們已經(jīng)是 Trunk Based Development！

總結(jié)

Trunk Based Development 使我的團(tuán)隊(duì)更加靈活。我們可以隨時(shí)發(fā)布我們的主分支，我們已經(jīng)沒有大的合并沖突了?？偸请S時(shí)準(zhǔn)備投入生產(chǎn)的主分支是持續(xù)交付的先決條件。功能切換是 A/B 測試的先決條件。它們幫助我們了解客戶真正想要什么，并使我們更有信心，因?yàn)槲覀冎揽梢噪S時(shí)禁用某個(gè)功能。結(jié)果就是：風(fēng)險(xiǎn)更小，創(chuàng)新更多。

譯者：王志宇

JFrog 中國研發(fā)工程師，曾在唯品會(huì)擔(dān)任研發(fā)工程師，擅長 Java，參與過多個(gè)互聯(lián)網(wǎng)平臺(tái)的研發(fā)和運(yùn)維工作，現(xiàn)專注于Devops 落地，持續(xù)集成、持續(xù)交付領(lǐng)域。

原文作者：Robert 原文地址: https://team-coder.com/from-git-flow-to-trunk-based-development/

歡迎轉(zhuǎn)載，但轉(zhuǎn)載請注明作者與出處。謝謝！