Git Branching Strategies: Git Flow, GitHub Flow, GitLab Flow, TBD

完整介紹 Git 分支策略 feat. Git Flow, GitHub Flow, GitLab Flow, TBD

@ 技術討論

前言

近期在維護不同規模的專案，想說可以了解一下不同 Git 分支策略的優缺點來替專案選擇適合的開發策略。現階段我最常接觸的是 Gitflow 的方式來進行開發，但發現這樣的策略在小型規模的專案（5 人以下）並沒有這麼靈活好用，恰巧可以在全新的專案上嘗試其他策略，觀察現有的分支策略痛點是這樣：

  • 對於剛起步的簡單專案來說相對過於複雜的流程
  • 太多的長分支，專案難有一個確定的開發中版本。
  • 害怕巨無霸分支合併後會不會有新問題冒出來。

有的人喜歡 GitFlow 有的人超討厭，而我想在這篇文章敞開想法去分析了解不同策略的優缺點。

Gitflow

Gitflow 是一種全面的分支策略，旨在覆蓋各種場景。開發者們創建以功能為單位的 feature 分支並且在完成時合併入 develop 分支，並且在需要發布時創建 release 分支用於測試調整，最終合併到主分支 main 並且正式發布（可以添加標籤用於標註版本）。

當發布後發生緊急問題時，會從 main 開一個 hotfix 分支出來進行修復，修復完成之後，會合併回 main 分支，也同時會合併一份到 develop 分支。

  • 優點：
    • 可預測的發布週期：從開發到測試到發布週期都非常明確，非常適合具有定期開發和發布節奏的團隊。
    • 增強合作：透過不同明確職責的分支分隔出特定的環境，適合大型團隊以及跨多個團隊的協作並行開發。
    • 有效處理多個產品版本：通過釋出分支和修補分支，Gitflow 使得團隊可以同時支持多個版本。比如，團隊可以在開發新版本的同時，維護和更新已發布的舊版本，確保所有版本都能及時得到支持和修補。
  • 缺點：
    • 流程相對複雜：由於分支眾多，管理分支對初學者或新團隊來說會提高負擔。
    • 發布週期相對緩慢：頻繁的短分支使用 Gitflow 意義不大，因此長分支是常態。緩慢的發布周期可能意味著更慢的反饋。
    • 累積技術債：長分支可能導致分支差異過大累積技術債在分支合併時造成衝突。

GitHub Flow

GitHub Flow 圍繞在一個活躍的開發分支通常是 main 運行，這個分支會直接部署到生產環境。功能和 BUG 修復是通過功能分支來實現的。這種方法鼓勵反饋循環和異步協作，在開源項目中很常見。

通常會用到一些 GitHub 平台提供的一些功能，例如 Pull Request（拉取請求，要求對方把自己程式碼納入專案中）、Fork（複製專案一份到自己的遠端儲存庫）、代碼審核（針對 PR 的討論功能）……等。

  • 優點：
    • 直覺且簡單：減少了分支管理的複雜性。
    • 快速反應與反饋：精簡的流程，適合快速開發和頻繁部署，可以更快的得到反饋。
    • 非常適合中小型團隊中的異步工作：由於流程簡單直接不需要等待長時間的集中合併，因此非常適合小型團隊中的成員進行異步工作。
  • 缺點：
    • 正式環境更容易出問題：在沒有適當測試和健全的 CI/CD 、代碼審核……等過程下更容易發布問題到生產環境。
    • 適合單一版本產品：基於簡單的結構，同時維護與管理多個發佈版本變得困難。

GitLab Flow

GitLab Flow 是 GitHub Flow 的變體，基本流程相同。

不過為了解決 GitHub Flow 在多版本或多狀態管理上的問題進行了一些調整，舉例來說開發者們會持續的推送進度到 main 分支上，當有預備要發佈的需求時透過挑選進度到不同用途的分支上的方式來解決部屬和版本管理的問題，例如：staging 分支用於測試環境、production 分支用於正式環境。

  • 優點：
    • GitHub Flow 的所有優點
    • 可應對不同版本和多環境。
  • 缺點：
    • 比 GitHub Flow 複雜一點

Trunk Based Development

主幹開發（Trunk Based Development）提倡使用單一共享的主幹分支，並消除長期存在的分支，在需要發布時直接從主幹建構 release 分支部屬。根據團隊規模的不同，這種方法有兩種變體：較小的團隊直接提交代碼到主幹，而較大的團隊則創建短期的功能分支，鼓勵頻繁整合較小的功能片段，以確保經常進行合併。

盡可能的快速迭代把問題給刷掉，減少了煩惱分支合併、測試環境與版本，強烈依賴團隊素質透過自動化測試來維持穩定。

  • 優點：
    • 追求極致快速的迭代與反饋
  • 缺點：
    • 依賴強大的自動化 CI / CD 與團隊素質來保證穩定性。
    • 有時候會需要功能切換🔗的機制，以避免未完成的功能出現在正式環境。

總結

我發現幾個重點因素可以幫助我們選擇適合的分支策略：專案類型、團隊素質、團隊種類。

  • 團隊素質：如果團隊具有強大的技術能力和自動化測試，主幹開發（Trunk Based Development）可能是一個不錯的選擇，因為它追求極致快速的迭代和反饋，並依賴強大的自動化 CI/CD 來保證穩定性。然而，如果團隊尚未具備這些能力，則較為結構化的策略如 Gitflow 可能更適合，因為它提供了明確的分支管理和發布週期。

  • 團隊種類：大型團隊和跨團隊合作的情況下，Gitflow 可能更適合，因為它能夠將開發、測試和發布流程清晰地分隔開來，並且支持同時維護多個版本。而對於中小型團隊或適應性較強的團隊，GitHub Flow 或 GitLab Flow 可能更適合，因為它們具有較少的流程和較快的反饋。

  • 專案類型：對於需要同時維護多個版本的軟件產品，如企業級應用或桌面軟件，Gitflow 可能更適合，因為它支持多版本的同時開發和維護。對於敏捷開發或需要快速迭代的專案，如網絡應用或移動應用，GitHub Flow 或 GitLab Flow 可能更適合，因為它們能夠提供較快的反饋和靈活的開發流程。

延伸閱讀