← Writing

Git: Git Flow, GitHub Flow, GitLab Flow, Trunk-based development

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

gitgithubgitlab

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

← Back to all posts