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

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

聊完了 Merge 和 Rebase 的差別 之後，接下來要進入重頭戲了 — 分支管理策略。當你的團隊越來越大、專案越來越複雜，你就需要一套明確的規則來管理分支，不然大家各做各的，最後合併的時候就會像打仗一樣混亂。

Git Flow 就是這樣一套規則。它由 Vincent Driessen 在 2010 年提出，可以說是最經典的分支管理模型。雖然現在有些人覺得它太複雜了，但了解 Git Flow 對理解其他更簡化的工作流程（像 GitHub Flow 和 GitLab Flow）很有幫助。

文章概覽

在本篇文章中，你會學到：

• Git Flow 的基本概念與流程
• 各類分支的用途（feature、develop、release、hotfix、master）
• 如何在實際專案中應用 Git Flow
• Git Flow 的優缺點
• 與其他分支模型的比較

Git Flow 的基本概念與流程

Git Flow 概述

Git Flow 定義了一套明確的流程和分支用途，主要包含兩個長期存在的分支：master 和 develop，這兩個分支在整個專案生命周期中始終存在，各自承擔不同的角色。

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 放穩定版本，develop 放開發中的東西，其他分支都是暫時的。

各類分支的用途

Master 分支

• 用途：存放生產環境的穩定版本。
• 特點：只能接受從 Release 或 Hotfix 分支合併的變更，確保每個版本都是經過測試和穩定的。

Develop 分支

• 用途：整合所有功能分支的變更，作為下一個發佈版本的基礎。
• 特點：是開發人員進行日常開發和整合的主要分支，所有新功能的開發都基於此分支進行。

Feature 分支

• 用途：用於開發新功能或修復特定問題。
• 命名規則：feature/<功能名稱>，例如 feature/login
• 生命周期：從 Develop 分支創建，完成開發後合併回 Develop 分支。

Release 分支

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

Hotfix 分支

• 用途：緊急修復生產環境中的問題。
• 命名規則：hotfix/<修復名稱>，例如 hotfix/login-bug
• 生命周期：從 Master 分支創建，完成後合併回 Master 和 Develop 分支。

如何在實際專案中應用 Git Flow

初始化 Git Flow

git flow init

按照提示設置分支前綴，通常使用默認設置就好。

創建功能分支

git flow feature start <feature-name>

完成功能分支並合併回 Develop

git flow feature finish <feature-name>

創建 Release 分支

git flow release start <version>

完成 Release 分支並合併回 Master 和 Develop

git flow release finish <version>

創建 Hotfix 分支

git flow hotfix start <hotfix-name>

完成 Hotfix 分支並合併回 Master 和 Develop

git flow hotfix finish <hotfix-name>

Git Flow 的優缺點

優點

• 結構明確：明確的分支命名和用途，方便團隊協作。
• 版本控制：有效管理版本發佈，降低生產環境風險。
• 靈活性：適用於中大型專案，支持多個並行開發任務。

缺點

• 複雜性：對於小型專案或單人開發可能過於繁瑣。說實話，如果你的團隊只有兩三個人，用 Git Flow 有點殺雞用牛刀。
• 流程固定：需要嚴格遵循流程，對團隊協作要求較高。

與其他分支模型的比較

Git Flow vs GitHub Flow

• Git Flow 更適合需要明確版本發佈和多個穩定分支的大型專案。
• GitHub Flow 更簡潔，適合持續部署和小型專案，只有 Master 和 Feature 分支。

Git Flow vs GitLab Flow

• GitLab Flow 結合了 Git Flow 和 GitHub Flow 的優點，提供更多靈活性，支持不同的工作流程模式。

實際案例

案例一：功能分支的合併

假設你有一個功能分支 feature-login，該分支完成了用戶登入功能的開發。

# 創建功能分支
git flow feature start login
 
# 完成功能開發後，合併回 Develop
git flow feature finish login

這將自動合併 feature-login 分支到 develop 分支，並刪除功能分支。

案例二：發布新版本

# 創建 Release 分支
git flow release start 1.0.0
 
# 在 Release 分支上進行最終測試和修正
# ...
 
# 完成 Release 分支，合併回 Master 和 Develop
git flow release finish 1.0.0

這將自動合併 Release 分支到 master 和 develop 分支，並打上版本標籤 v1.0.0。

案例三：緊急修復

# 創建 Hotfix 分支
git flow hotfix start fix-login-bug
 
# 修復生產環境中的登入錯誤
# ...
 
# 完成 Hotfix 分支，合併回 Master 和 Develop
git flow hotfix finish fix-login-bug

這將自動合併 Hotfix 分支到 master 和 develop 分支，並打上版本標籤。

最佳實踐提示

• 遵循命名規則：使用一致的分支命名規則，如 feature/<name>、release/<version>、hotfix/<name>，以保持分支結構的清晰。
• 定期同步 Develop 分支：確保 Develop 分支保持最新，定期從 Master 分支合併或變基，減少合併衝突。
• 代碼審查與測試：在合併分支前，通過 Pull Request 進行代碼審查和測試，確保代碼質量和穩定性。
• 自動化部署：結合 CI/CD 工具，自動化 Release 和 Hotfix 的部署流程，提升發佈效率和可靠性。

常見問題解答

問：Git Flow 適用於哪些專案？

答：Git Flow 適用於中大型專案，特別是那些需要明確版本發佈和多個穩定分支的專案。對於小型專案或快速迭代的環境，可能需要選擇更簡潔的分支管理策略，如 GitHub Flow 或 GitLab Flow。

問：如果我的團隊不使用 Git Flow，會有什麼影響？

答：不使用 Git Flow 不會怎樣，但團隊需要自行制定分支管理策略。重點是大家要有共識，不然分支結構混亂或版本管理不當就會很頭痛。

問：Git Flow 和 GitHub Flow 可以結合使用嗎？

答：可以根據專案需求靈活結合使用。例如，可以在 Git Flow 的基礎上，採用 GitHub Flow 的簡化流程來處理某些特定的開發任務。

總結

Git Flow 提供了一套完整且結構化的分支管理模型，適用於中大型專案和需要明確版本發佈的團隊。通過明確分支的用途和流程，Git Flow 有助於提升團隊協作效率，降低發佈風險。然而，對於小型專案或快速迭代的環境，可能需要選擇更簡潔的分支管理策略。

參考資源

• Git Flow 官方文件
• Pro Git 書籍 - 分支管理

---

延伸閱讀

• Merge vs Rebase — 了解合併策略的基礎
• GitHub Flow — 更簡潔的分支管理策略
• GitLab Flow — 靈活的分支管理策略
• Release 管理 — 版本發佈的完整流程
• CommitLint 規範 — commit 訊息規範
• Release 方法論 — 更廣泛的 Release 策略討論