跳至主要內容
LinPolly
文章 開發工具

Git 分支策略最佳實踐：從 Git Flow 到 Trunk-Based

9 分鐘閱讀 1,000 字

Git 分支策略最佳實踐：從 Git Flow 到 Trunk-Based

選擇合適的 Git 分支策略，對團隊的開發效率和發佈品質有著深遠影響。沒有放諸四海皆準的答案，但了解各種策略的優缺點，能讓你根據團隊規模和發佈頻率做出最適合的選擇。

主流分支策略概覽

目前業界常見的分支策略主要有三種：

  1. Git Flow — 適合有固定發佈週期的專案
  2. GitHub Flow — 適合持續部署的 Web 服務
  3. Trunk-Based Development — 適合高頻發佈、DevOps 成熟的團隊

Git Flow 詳解

Git Flow 由 Vincent Driessen 在 2010 年提出，定義了嚴格的分支結構：

main          ─────●─────────────────────●──────
                   │                     │
develop       ─────●──●──●──●──●──●──●──●──────
                      │        │
feature/xxx   ─────────●──●──●─┘
release/1.0              │
                    ─────●──●──●──┐
hotfix/urgent                     ●──●

主要分支：

  • main：永遠是可上線的穩定版本
  • develop：整合所有功能的開發分支

支援分支：

  • feature/*：新功能開發，從 develop 切出，合併回 develop
  • release/*：準備發佈，從 develop 切出，合併到 main 和 develop
  • hotfix/*：緊急修復，從 main 切出，合併到 main 和 develop
# 開始新功能
git checkout develop
git checkout -b feature/user-authentication

# 完成功能，合併回 develop
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

# 建立發佈分支
git checkout -b release/1.2.0 develop
# 修正版本號、更新 CHANGELOG...
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0

Git Flow 適用場景： 有明確版本號的桌面應用、SDK、開源函式庫。

GitHub Flow

GitHub Flow 大幅簡化了 Git Flow，核心只有一個規則：main 永遠是可部署的，功能透過 Pull Request 合併。

main     ─────●────────────●────────●──────
              │            │        │
feature-a ────●──●──●──────┘
feature-b          ────●──●──●──────┘
# 1. 從 main 建立功能分支（分支名應有描述性）
git checkout -b feat/add-oauth-login

# 2. 開發、提交
git add -p
git commit -m "feat: add Google OAuth login flow"

# 3. 推送並開 Pull Request
git push -u origin feat/add-oauth-login
# 在 GitHub 開 PR，等待 Code Review 和 CI 通過

# 4. 合併後立即部署
# PR merge → 自動觸發 CI/CD → 部署到正式環境

Trunk-Based Development

Trunk-Based Development（TBD）是 DevOps 高效能團隊（如 Google、Facebook）採用的策略。所有開發者每天至少一次將程式碼合併到 main（trunk），避免長期分支帶來的合併地獄。

# 短命分支：通常不超過 1-2 天
git checkout -b fix/login-validation
# 修改...
git commit -m "fix: validate email format on login"
git push origin fix/login-validation
# PR → 快速 Review → 當天合併

Feature Flags 是 TBD 的關鍵工具：

// 未完成的功能用 Feature Flag 隱藏
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckoutFlow />
}
return <OldCheckoutFlow />

提交訊息規範：Conventional Commits

無論採用哪種分支策略，清晰的提交訊息都至關重要：

<type>(<scope>): <description>

[optional body]

[optional footer]

常用 type：

  • feat：新功能
  • fix：修復 bug
  • docs：文件變更
  • refactor：重構（不新增功能、不修 bug）
  • test：新增或修改測試
  • chore：建置工具、依賴更新
git commit -m "feat(auth): add JWT refresh token rotation"
git commit -m "fix(api): handle null user in profile endpoint"
git commit -m "refactor(cart): extract price calculation to service"

分支保護規則

在 GitHub 中設定分支保護是保障程式碼品質的基本措施：

# .github/branch-protection.yml 概念（需在 GitHub UI 或 API 設定）
branch: main
required_status_checks:
  - ci/test
  - ci/lint
require_pull_request_reviews:
  required_approving_review_count: 1
enforce_admins: true
restrict_pushes: true  # 禁止直接 push 到 main

如何選擇策略

情境 建議策略
行動 App / SDK，有版本號 Git Flow
持續部署的 SaaS 產品 GitHub Flow
高頻發佈，DevOps 成熟 Trunk-Based
小型團隊（1-3 人） GitHub Flow
大型團隊，多功能並行 GitHub Flow + Feature Flags

總結

分支策略不是選一個就固定不變，隨著團隊成長和發佈頻率提高，策略也應該演進。許多成熟團隊的路徑是：Git Flow → GitHub Flow → Trunk-Based Development。從複雜到簡單，從隔離到整合，最終目標都是縮短功能從開發到上線的週期。

#Git #Docker

分享這篇文章