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

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

Git Flow 的問題

合并沖突

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

構建

功能分離

在合并到一個分支之前，你是不能測試兩個功能的組合。當你在單獨的分支機構中開發幾天甚至幾周的功能時，由于兩個功能的相互作用而產生的問題發生了。當你對這些問題反映遲緩時，你可能不得不改變你為新功能編寫的代碼的更多部分。這意味著你已經浪費了很多的時間來創建你不再需要的代碼。

許多不同的功能分支也可能會讓你的軟件的手動測試人員感到困惑。他們總是必須知道在哪個臨時環境中可以找到新功能。不同的階段環境通常也意味著不同的構建任務，用于監控任務的不同屏幕等。

不可預測的發布

Git Flow 還有另一個問題，這是以上兩點的結果：如果功能分支尚未合并，則不可能知道需要多少時間才能發布。你不知道它是因為你不知道哪個合并會發生沖突，你也不知道新功能將如何相互影響。不能在任何時候發布將使你缺乏信心。

解決方案

Trunk Based Development

好消息！上述所有問題都有解決方案，就是Trunk Based Development。你只有一個主分支，即主干（Master 或者 Mainline）。不再有開發分支，也沒有存在時間很久的分支。所有的提交都會盡快合并到主干中，至少每天一次。通過如此迅速的合并到主干，合并沖突變的非常罕見。使用短時間分支是避免合并沖突的4個簡單技巧之一。即使你遇到了合并沖突，也可能很容易解決，因為從上次合并到主干后變化并不那么大。不同功能之間的干擾立即可見，可以在功能正在進行時測試。

基于主干的開發也將鼓勵你的團隊以小的 Step 思考和工作，從而做到小的提交，這些提交可以快速合并到主干。通常，小 Step 可以減少錯誤數量，并有助于創建模塊化設計。

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

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

功能切換

當我在 HolidayCheck 向我的團隊介紹 Trunk Based Development 的開發時，為了能夠迅速的將代碼提交到主干，有一個第一步是絕對必要的！在開始我們的分支結構之前，我們必須確保我們使用能夠盡快的融入開發分支的并且存在時間很短的分支。解決辦法相當簡單，我們開始使用功能切換——源碼中的一些開關決定功能是否處于活動狀態。

只要功能沒有準備好被發布，它就會被禁用。這使我們可以在不破壞任何東西的情況下將其推入到開發分支。開發人員和手動測試人員可以在一些設置中啟用對于普通用戶隱藏的每個功能。開發分支隨時準備被發布，因為未完成的功能將被關閉。他們將被推送到客戶，但是是不可見狀態的。一旦某個功能完成，他就會打開并在下一個版本中可用。

當我們在代碼中切換這些功能時，我們意識到它們不僅在功能開發的時候有用！即使功能完成，在代碼中保持切換也是非常好的。如果我們有可能為所有用戶遠程控制切換，那么只要我們發現他對我們的轉化率或其他關鍵數字有不良影響，我們就可以快速停用該功能。此外，如果發生任何錯誤或者服務器的流量負載過高，我們總是能夠立即關閉該功能。這一點尤其重要，因為我們必須等待多天，直到蘋果回顧，出了我們的 IOS 應用程序的新版本。能夠在沒有新版本的情況下禁用功能是一個非常強大的武器。

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

一個分支約定所有

現在我們可以快速地將我們的功能分支合并到開發分支中（因為未完成的功能已經停用），我們可以隨時發布開發分支。問題是：我們是否還需要一個開發和一個主分支？答案是：不需要。我們可以直接把所有東西都交給 Master 而不是 Develop 分支。Master 隨時準備投入生產（不要忘記每當有東西被推入 Master 時，都要運行所有的測試）。如果我們想創建一個發行版本，我們可以直接從主分支創建，或者為此創建一個發行版分支。最新發布的提交標有 Git tag。所以引入功能切換后的第二步是刪除開發分支！在這里，我們已經是 Trunk Based Development！

總結

Trunk Based Development 使我的團隊更加靈活。我們可以隨時發布我們的主分支，我們已經沒有大的合并沖突了。總是隨時準備投入生產的主分支是持續交付的先決條件。功能切換是 A/B 測試的先決條件。它們幫助我們了解客戶真正想要什么，并使我們更有信心，因為我們知道可以隨時禁用某個功能。結果就是：風險更小，創新更多。

譯者：王志宇

JFrog 中國研發工程師，曾在唯品會擔任研發工程師，擅長 Java，參與過多個互聯網平臺的研發和運維工作，現專注于Devops 落地，持續集成、持續交付領域。

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

歡迎轉載，但轉載請注明作者與出處。謝謝！