GitHub Flow：簡單高效的分支管理模型

開分支、寫 code、開 PR、review、merge、deploy。GitHub Flow 就這六步。

先講結論

如果你的團隊在做持續部署、專案不需要同時維護多個版本，GitHub Flow 就是你要的。它把 Git Flow 的五種分支砍到只剩兩種：main 和 feature。簡單到你一天就能學會。

流程圖

flowchart TD
    A[main 分支] -->|1. 建立分支| B[feature/xxx]
    B -->|2. 開發 & 提交| C[推送到遠端]
    C -->|3. 開 Pull Request| D[Code Review]
    D -->|4. 審查通過| E{合併到 main}
    D -->|需要修改| B
    E -->|5. 自動部署| F[Production]

    style A fill:#4CAF50,color:#fff
    style F fill:#2196F3,color:#fff

跟 Git Flow 比一下，是不是簡單多了？沒有 develop、release、hotfix 那些分支，就是一條主線加上功能分支。

實際操作

# 1. 從 main 開分支
git checkout -b feature/signup-system
 
# 2. 開發、提交、推送
git add .
git commit -m "Add signup feature"
git push origin feature/signup-system
 
# 3. 在 GitHub 上開 PR
# 4. 團隊 review
# 5. 合併到 main
# 6. 自動部署到 production

就這樣。沒有什麼 develop 分支、release 分支的概念。main 就是 production，永遠保持可部署狀態。

GitHub Flow 的核心精神

main 分支永遠是可部署的。 這代表你合進 main 的每一個 PR 都必須經過 review 和測試。沒有「先合進去 develop 之後再說」這種事。

小步快跑。 功能拆小、PR 拆小、頻繁合併。不要開一個分支寫三個月才回來合 — 到時候衝突會讓你懷疑人生。

PR 就是 code review 的場所。 所有討論、修改建議、測試結果都在 PR 裡面。這不只是品質把關，也是團隊知識共享的方式。

那 hotfix 怎麼辦？

GitHub Flow 裡沒有獨立的 hotfix 分支。發現 bug？跟平常一樣開分支、修復、開 PR、merge、deploy。因為流程夠簡單，hotfix 的速度反而比 Git Flow 快。

搭配的工具

• GitHub Actions：自動化測試和部署，PR 一合併就自動 deploy
• PR Template：標準化 PR 描述，提升 review 效率
• Branch Protection Rules：強制 code review、通過 CI 才能 merge

什麼時候不該用 GitHub Flow？

老實說，如果你的專案需要同時維護多個版本（像 v1.x 和 v2.x 並行），或者需要在正式上線前有完整的 staging 驗證流程，GitHub Flow 就不夠用了。這時候考慮 GitLab Flow 或 Git Flow。

---

GitHub Flow 的美在於它的簡單。但簡單不代表隨便 — 它背後的假設是你有完善的自動化測試和 CI/CD。沒有這些基礎設施就用 GitHub Flow，跟不綁安全帶開快車一樣刺激。

---

參考資源

• GitHub Flow 官方文件

延伸閱讀

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