前言

當你開始與團隊協作開發時，一定會遇到這個問題：「大家都在同一個專案上改 code，要怎麼避免互相踩到？」

這就是分支策略（Branching Strategy）要解決的問題。而 GitHub Flow 是目前最受歡迎的分支策略之一，因為它簡單、直覺，而且非常適合現代的持續部署（Continuous Deployment）工作流程。

學習目標

讀完本篇後，你將能夠：

• 理解 GitHub Flow 的核心概念與六個步驟
• 了解 GitHub Flow 與 Git Flow 的差異
• 判斷何時適合使用 GitHub Flow

前置知識

在開始之前，你需要具備：

• 基本 Git 操作（commit, push, pull）
• 了解什麼是分支（branch）

GitHub Flow 是什麼？

GitHub Flow 是一種簡單的分支策略，核心理念只有一個：

main 分支永遠是可部署的狀態

這意味著：

• 所有開發工作都在功能分支（feature branch）上進行
• 完成後透過 Pull Request（PR） 合併回 main
• main 分支的程式碼隨時都可以部署到正式環境

聽起來很簡單對吧？這正是 GitHub Flow 的優點——簡單到幾乎不需要學習。

GitHub Flow 的六個步驟

讓我們透過一個實際情境來理解這六個步驟。

假設你要在專案中新增一個「使用者登入」功能：

步驟 1：從 main 建立分支

# 先確保 main 是最新的
git checkout main
git pull origin main

# 建立並切換到新分支
git checkout -b feature/user-login
Code language: PHP (php)

重點：分支名稱要能描述這個功能，讓其他人一眼就知道你在做什麼。

常見的命名慣例：

• feature/功能名稱 – 新功能
• fix/問題描述 – 修復 bug
• docs/文件名稱 – 文件更新

步驟 2：在分支上開發並 commit

# 開發過程中，持續 commit 你的進度
git add .
git commit -m "Add login form UI"

git add .
git commit -m "Implement login API call"

git add .
git commit -m "Add login validation"
Code language: PHP (php)

重點：每個 commit 應該是一個有意義的變更單位，而不是「每天下班前 commit 一次」。

步驟 3：Push 到遠端

git push origin feature/user-login

重點：即使功能還沒完成，也建議定期 push。這樣可以：

• 備份你的程式碼
• 讓其他人看到你的進度
• 方便在不同電腦上繼續開發

步驟 4：發起 Pull Request（PR）

在 GitHub 網站上，點擊「New Pull Request」，選擇你的分支要合併到 main。

PR 是 GitHub Flow 的核心環節，它提供了：

• 程式碼審查（Code Review）：讓其他人檢查你的程式碼
• 討論空間：針對特定程式碼行留言討論
• CI/CD 整合：自動執行測試、檢查程式碼品質

步驟 5：討論與審查

團隊成員會：

• 閱讀你的程式碼變更
• 提出問題或建議
• 要求修改或直接通過

如果需要修改，你只需要在同一個分支上繼續 commit 並 push，PR 會自動更新。

步驟 6：合併並部署

當 PR 通過審查後：

1. 點擊「Merge Pull Request」
2. 刪除已合併的分支（GitHub 會提示你）
3. main 更新後，可以立即部署到正式環境

GitHub Flow vs Git Flow：該選哪個？

你可能聽過另一個叫做 Git Flow 的分支策略。讓我們比較一下：

Git Flow 的結構

main ─────────────────────────────────────────────>
  │                                    ↑
  └── develop ──────────────────────────
        │           ↑         ↑
        ├── feature/A ────────┘         │
        └── feature/B ──────────────────┘

Git Flow 有多個長期分支：

• main：正式版本
• develop：開發中版本
• feature/*：功能分支
• release/*：發布準備
• hotfix/*：緊急修復

GitHub Flow 的結構

main ─────────────────────────────────────────────>
  │         ↑              ↑
  ├── feature/A ───────────┘              │
  └── feature/B ──────────────────────────┘

GitHub Flow 只有：

• main：唯一的長期分支
• feature/*：短期功能分支

比較表

如何選擇？

選 GitHub Flow 當你：

• 團隊規模較小（2-10 人）
• 需要快速迭代、持續部署
• 專案是 Web 應用或 SaaS 服務
• 不需要維護多個正式版本

選 Git Flow 當你：

• 需要維護多個版本（如桌面軟體、SDK）
• 有固定的發布週期
• 團隊規模較大，需要更嚴格的流程
• 正式版與開發版需要明確區分

GitHub Flow 的適用場景

最適合的情境

1. 持續部署的 Web 應用
   • 每個 PR 合併後自動部署
   • 用戶永遠使用最新版本
2. 小型敏捷團隊
   • 溝通成本低
   • 快速決策、快速交付
3. 開源專案
   • 外部貢獻者容易理解流程
   • PR 機制天然適合開源協作

不太適合的情境

1. 需要維護多版本的軟體
   • 例如：v1.x 和 v2.x 同時維護
   • 此時 Git Flow 更適合
2. 有嚴格合規要求的專案
   • 需要詳細的發布記錄
   • 需要明確的版本里程碑

常見問題

Q: 如果 main 更新了，我的分支怎麼辦？

在發起 PR 前，建議先同步 main 的最新變更：

git checkout main
git pull origin main
git checkout feature/user-login
git merge main
# 或使用 rebase
git rebase main
Code language: PHP (php)

Q: PR 一定要別人審查嗎？

技術上不強制，但強烈建議。即使是小團隊，Code Review 也能：

• 發現潛在問題
• 分享知識
• 維持程式碼品質一致性

Q: 一個 PR 應該多大？

越小越好。建議：

• 一個 PR 只做一件事
• 控制在 200-400 行程式碼變更
• 如果功能太大，拆成多個 PR

重點整理

1. GitHub Flow 是簡單的分支策略：只有 main 一個長期分支，所有開發都在功能分支進行
2. 六個步驟：建立分支 → 開發 commit → Push → 發起 PR → 審查討論 → 合併部署
3. 與 Git Flow 的差異：GitHub Flow 更簡單，適合持續部署；Git Flow 更完整，適合週期性發布
4. 適用場景：Web 應用、小團隊、持續部署、開源專案

下一步

在下一篇文章中，我們將實際操作 GitHub Flow 的第一步：建立 Branch 與 PR。你將學會如何在實際專案中開始使用這個工作流程。