Terry Yao's Blog

GitLab Flow：靈活的分支管理模型

閱讀時間約 7 分鐘

cover

GitLab Flow：靈活的分支管理模型

看完了 Git Flow 和 GitHub Flow，你可能會想：「Git Flow 太複雜，GitHub Flow 又太簡單，有沒有折中的方案？」有的！GitLab Flow 就是那個「剛剛好」的選擇。

前言

GitLab Flow 是一種靈活的分支管理模型，結合了 Git Flow 和 GitHub Flow 的優點。它由 GitLab 提出，強調「上游優先」的原則，並支持多環境的部署策略，適合中大型專案和快速迭代的開發環境。

簡單來說，GitLab Flow 的核心思想是：程式碼永遠從上游（master）往下游（production）流動，不走回頭路。

GitLab Flow 的基本概念

GitLab Flow 的核心思想是：

  1. 只存在一個主分支 master，它是所有分支的上游。
  2. 創建新的分支來開發新功能或修復 bug。
  3. 當開發完成時，發起一個 Merge Request 請求合併。
  4. 在 Merge Request 中進行代碼審查和測試。
  5. 如果代碼審查通過，就可以合併到 master 分支。
  6. 合併後，master 分支上的代碼可以部署到不同環境。

GitLab Flow 流程圖

flowchart TD
    A[feature 分支] -->|Merge Request| B[master 分支]
    B -->|自動部署| C[Pre-production 環境]
    C -->|測試通過| D[Production 環境]
    
    E[hotfix 分支] -->|Merge Request| B
    
    subgraph 環境分支
        C
        D
    end
    
    subgraph 開發分支
        A
        E
    end
    
    style B fill:#4CAF50,color:#fff
    style D fill:#2196F3,color:#fff

跟 GitHub Flow 比起來，GitLab Flow 多了「環境分支」的概念。這讓你可以在不同環境（開發、測試、正式）之間更好地管理程式碼的流動。

如何使用 GitLab Flow

  1. 從 master 分支創建一個新的分支：

    git checkout -b feature/new-feature

  2. 在新分支上進行開發和提交：

    git add .
git commit -m "Add new feature"
git push origin feature/new-feature

  3. 在 GitLab 上發起一個 Merge Request：

    • 在 GitLab 頁面上，點擊 Merge Request 按鈕。
    • 填寫 MR 標題和描述，描述本次 MR 的內容。

  4. 在 MR 頁面進行代碼審查和測試：

    • 其他開發者可以查看變更內容並進行代碼審查。
    • 可以運行自動化測試來確保新功能的正確性。

  5. 合併 MR 到 master 分支：

    • 如果代碼審查通過，就可以點擊 Merge 按鈕將分支合併到 master。
    • 合併後，master 分支上的代碼就是最新的版本。

  6. 部署到生產環境：

    • 合併到 master 後，程式碼會先部署到 pre-production 環境。
    • 在 pre-production 測試通過後，再部署到 production 環境。

各類分支的用途

Master 分支

  • 用途：存放生產環境的穩定版本。
  • 特點：所有的變更都必須通過測試後才能合併到此分支。

Feature 分支

  • 用途：用於開發新功能或修復特定問題。
  • 命名規則：feature/<功能名稱>，例如 feature/login
  • 生命周期：從 master 分支創建，完成開發後合併回 master。
  • 最佳實踐：每個 Feature 分支應專注於一個單一功能，避免功能之間的耦合。

Environment 分支

  • 用途：用於不同的部署環境，如 pre-production 和 production。
  • 特點：這些分支用於測試和驗證功能，確保在正式環境中穩定運行。這是 GitLab Flow 跟 GitHub Flow 最大的不同。

Release 分支

  • 用途：準備新版本的發佈，進行最終測試和修正。
  • 命名規則：release/<版本號>，例如 release/1.0.0
  • 生命周期：從 master 分支創建，完成後合併回 master。

優點和缺點

優點

  • 靈活性高：適合快速迭代和持續發佈的開發環境。團隊可以根據不同的需求快速創建和刪除分支。
  • 上游優先：確保 master 分支始終處於可部署狀態，所有合併的變更都經過測試。
  • 支持多環境：可以根據需要創建不同的環境分支，如開發、預發和生產環境。這點在有多個部署環境的專案中超好用。

缺點

  • 不適合小型專案：對於小型專案，過多的分支管理可能會增加複雜性。
  • 依賴持續集成：需要穩定的 CI/CD 流程支持，否則可能影響部署效率。

實際案例

案例一：持續發布的 Web 應用開發

在一個需要頻繁發布新功能的 Web 應用專案中，團隊採用 GitLab Flow 來管理分支和發佈流程。每個新功能都在獨立的 Feature 分支上開發，完成後通過 Merge Request 合併到 master 分支，並依序部署到 pre-production 和 production 環境。

案例二：版本發佈管理

在一個大型專案中，團隊使用 GitLab Flow 來管理版本發佈。每個穩定版本都從 master 創建一個新的版本分支，並在該分支上進行修復和更新。當發現 bug 時，團隊會從版本分支創建 Hotfix 分支，修復完成後合併到 master 和版本分支。

總結

GitLab Flow 提供了一套靈活且結構化的分支管理模型，適合需要快速迭代和持續發佈的專案。它結合了 Git Flow 的結構性和 GitHub Flow 的簡潔性，加上環境分支的概念，讓程式碼的部署流程更加清晰可控。

如果你的團隊需要在多個環境之間管理部署，GitLab Flow 會是個很好的選擇。

參考資源

延伸閱讀

關係圖譜

反向連結