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

Git Flow 太複雜，GitHub Flow 又太簡單？GitLab Flow 就是那個「剛剛好」的選擇。

先講結論

GitLab Flow 在 GitHub Flow 的基礎上加了「環境分支」的概念。如果你的團隊需要在 staging 驗證完才上 production，但又不想搞 Git Flow 那麼多分支，GitLab Flow 就是你的菜。核心原則：程式碼永遠從上游往下游流，不走回頭路。

流程圖

flowchart TD
    A[feature 分支] -->|Merge Request| B[master 分支]
    B -->|自動部署| C[Pre-production 環境]
    C -->|測試通過| D[Production 環境]
    E[hotfix 分支] -->|Merge Request| B

    style B fill:#4CAF50,color:#fff
    style D fill:#2196F3,color:#fff

跟 GitHub Flow 比起來，多了環境分支（pre-production、production）。這讓你可以在不同環境之間管理程式碼的流動，而不是 merge 到 main 就直接上線。

操作流程

# 從 master 開分支
git checkout -b feature/new-feature
 
# 開發完成，推上去
git add .
git commit -m "Add new feature"
git push origin feature/new-feature
 
# 在 GitLab 上開 Merge Request
# Code review + 自動測試
# 合併到 master
# 自動部署到 pre-production
# Pre-production 測試通過後，部署到 production

GitLab Flow vs 其他兩個

跟 GitHub Flow 的差別：GitHub Flow 合到 main 就直接 deploy。GitLab Flow 多了環境分支，程式碼要經過 pre-production 測試才能到 production。如果你的產品不能接受「merge 就上線」的風險，GitLab Flow 更穩。

跟 Git Flow 的差別：Git Flow 有 develop、release、hotfix 一堆分支。GitLab Flow 更簡潔，用環境分支取代了大部分的流程分支。

什麼時候該用 GitLab Flow？

• 你需要 staging → production 的部署流程
• 你不想要 Git Flow 那麼複雜的分支結構
• 你的團隊有多個部署環境需要管理
• 你同時需要維護多個版本的 release 分支

反過來說，如果你的團隊就是 merge 就 deploy、不需要 staging 驗證，那 GitHub Flow 就夠了。

---

三種 Flow 都介紹完了。選哪個？看你的團隊規模、部署流程、產品特性。沒有最好的，只有最適合的。但說真的，不管選哪個，有共識比選哪個更重要。

---

參考資源

• GitLab Flow 官方文件

延伸閱讀

• Git Flow — 完整的分支管理模型
• GitHub Flow — 簡潔的分支管理策略
• Release 管理 — 版本發佈的完整流程
• CommitLint 規範 — commit 訊息規範