November 11, 2023

Viiisit [Git] - Git Flow, GitHub Flow, GitLab Flow, Trunk-based development!

#git#github#gitlab

Git 是在軟體開發上常用的版本控制工具,要如何有效對分支進行管理以及使用 Git 進行協作和開發呢?
以下分享四種常見的 Flow 分別為 Git Flow, GitHub Flow, GitLab Flow, Trunk-based development,在往後的團隊合作上可以好好的利用!

  1. Git Flow:
    Git Flow 明確定義特定分支的責任,例如將 main/master 分支用於 production,使用 develop 分支進行主開發,feature 分支用於開發新功能,release 分支作為通往production 之前把關的閘門,以及 hotfix 分支用於解決緊急問題。

    優點:

    • 適用於大型團隊,並在多個團隊之間協調工作。
    • 有效處理多個產品版本。
    • 對每個分支有清晰的責任。
    • 通過標籤輕鬆尋找生產版本。

    缺點:

    • 由於分支眾多,可能導致合併衝突,使得複雜度增加。
    • 由於多步驟流程,開發和發布的頻率可能較慢。
    • 需要團隊共識並致力於堅持該策略。

    Git Flow

  2. GitHub Flow:
    GitHub Flow 沒有 release 分支,通過開發分支(通常是 main 或 master),直接部署到生產環境。
    使用長期存在的功能分支來實現功能和錯誤修復,在 open-source projects 中很常見。

    優點:

    • 更快的反饋週期和更短的生產週期。
    • 適用於較小團隊的非同步工作。
    • 與 Git Flow 相比,更敏捷且更容易理解。

    缺點:

    • 合併功能分支也就是這新的分支已經準備好投入 production,可能在沒有正確測試和堅固的 CI/CD 流程的情況下引入錯誤。
    • 長期存在的分支可能使流程變得複雜。
    • 由於合併衝突增多,對於較大的團隊來說難以擴展。
    • 同時支持多個發布版本可能會變得困難。

    GitHub Flow

  3. GitLab Flow:
    GitLab Flow 在 Git Flow 和 GitHub Flow 之間取得平衡。
    採用了 GitHub Flow 的分支策略,依然有 feature branch 與 master branch,但在 master 之外,增加專門用來配合交付與部署的 branch,例如 pre-production branch、production branch 或 特定版號 -stable。

    上游優先 Upstream First
    GitLab Flow 主要原則為上游優先(upsteam first)只存在一個主分支 master,此分支是所有分支的上游。所以分支合併的順序很重要,要一次和並且確保通過測試才可以往下游合併,除非是緊急情況,才允許跳過上游直接在下游操作合併。

    優點:

    • CI/CD
    • 能夠有效處理多個發布版本或階段。
    • 比 Git Flow 更簡單。
    • 以精簡的方式專注於質量。

    缺點:

    • 當維護多個版本時,複雜性會增加。
    • 與 GitHub Flow 相比更為複雜。

    GitLab Flow

  4. Trunk-based development
    Trunk-based development(TBD)是一種軟體開發的策略,強調在一個主要分支(通常是稱為 trunk 或 main 的分支)上進行大部分的開發工作,而不是使用較長壽命的特性分支。這種方法的目標是促使團隊更快速地進行迭代和持續交付,並減少分支引入的複雜性。

    a. 持續整合: Trunk 鼓勵持續整合,開發者經常將變更合併到主分支。這種方法確保了代碼的定期整合,有助於在開發過程的早期識別和解決集成問題,減少了大型和複雜的合併風險,使團隊更早地發現問題。

    b. 團隊協作: 通過在共享的主分支上工作,開發者可以更有效地協作。多個團隊成員可以同時在各種功能上工作,而無需使用長時間的特性分支。

    c. 敏捷和迭代開發: Trunk 使團隊能夠向生產環境交付更小、增量的變更。這種迭代的方法有助於從用戶和利益相關者那裡更快地獲得反饋,使根據他們的反饋進行調整和變更變得更容易。

    d. 減少代碼複雜性: 長期存在的特性分支可能導致代碼的顯著分歧和複雜性。相比之下,Trunk-based development 通過最小化分支分開的時間,使代碼庫更容易維護。

    e. 更快的上市時間: Trunk 縮短了開發和部署之間的時間,使新功能更快地交付給最終用戶,支持持續交付和 DevOps 實踐,幫助組織實現更短的發布周期,迅速回應市場需求。

    f. 提高代碼質量和穩定性: 定期將代碼變更整合到主分支中促進了問題的早期識別和解決。這種做法還激勵開發者創建更簡單、自包含的代碼變更進行測試和驗證。

    優點:

    • 快速迭代和交付。
    • 減少分支合併的複雜性。
    • 更容易檢測和修復問題。
    • 鼓勵小型增量的變更。

    缺點:

    • 不適用於所有項目,特別是對於需要長期特性分支的大型項目。
    • 可能需要更強大的自動化測試基礎。

    Trunk Based Development


參考資料:
Introducing the Space Git Flow
Choosing the Right Git Branching Strategy: A Comparative Analysis
初探 GitLab Workflow & GitLab Flow
A guide to trunk-based development