Git Flow：完整的分支管理模型

cover

Git Flow 是分支管理界的「全套西裝」— 很正式、很完整，但不是每個場合都需要。

先講結論

Git Flow 適合中大型專案、需要明確版本發佈的團隊。如果你的團隊只有兩三個人、專案不需要同時維護多個版本，那 GitHub Flow 可能更適合你。但就算不用 Git Flow，理解它對理解其他工作流程很有幫助。

五種分支，各司其職

flowchart LR
    subgraph 長期分支
        M[master<br/>穩定版本]
        D[develop<br/>開發整合]
    end
    subgraph 短期分支
        F[feature/*<br/>新功能開發]
        R[release/*<br/>發佈準備]
        H[hotfix/*<br/>緊急修復]
    end
    D -->|建立| F
    F -->|合併回| D
    D -->|建立| R
    R -->|合併回| M
    R -->|合併回| D
    M -->|建立| H
    H -->|合併回| M
    H -->|合併回| D

看起來分支很多？其實邏輯很簡單：

master：只放穩定版本，每個 commit 都是可以上線的
develop：開發主線，所有功能在這裡整合
feature/*：開發新功能用的，從 develop 開出來，完成後合回 develop
release/*：準備發佈用的，從 develop 開出來，完成後合回 master + develop
hotfix/*：線上緊急修復用的，從 master 開出來，完成後合回 master + develop

實際怎麼操作？

# 開發新功能
git flow feature start login
# ...寫 code...
git flow feature finish login
 
# 準備發佈
git flow release start 1.0.0
# ...最後測試和修正...
git flow release finish 1.0.0
 
# 緊急修復
git flow hotfix start fix-login-bug
# ...修 bug...
git flow hotfix finish fix-login-bug

沒裝 git-flow 工具？用原生指令也行，就是 checkout + merge 的組合。但 git flow CLI 會幫你自動處理合併和刪除分支，省事很多。

Git Flow 的問題

說實話，Git Flow 有點過時了。2010 年提出的時候很前衛，但在 CI/CD 普及的今天，它的問題越來越明顯：

流程太重，小改動也要走完整流程
develop 和 master 分開維護容易出問題
不適合持續部署的團隊

連原作者 Vincent Driessen 自己都在 2020 年補充說：如果你的團隊在做持續部署，GitHub Flow 可能更適合。

那什麼時候該用 Git Flow？

你的產品需要同時維護多個版本（例如 v1.x 和 v2.x）
你有明確的 release 週期（例如每兩週發一版）
你的團隊超過 10 人，需要嚴格的分支管理

不符合以上條件？看看 GitHub Flow 或 GitLab Flow。

Git Flow 就像手排車 — 給你最大的控制權，但大部分人開自排就夠了。選工具跟選車一樣，適合自己最重要。

參考資源

Git Flow 原始文章

Terry Yao's Blog

分類

目錄