現代化 Git Flow（Trunk-Based + Release Tagging + Hotfix）
本篇介紹一種 極簡、易維護、CI/CD 友善的 Git Flow，適合希望減少分支複雜度、提高交付速度的團隊。
此流程結合：
- Trunk-Based Development（主幹開發）
- Semantic Versioning（語義化版本）
- Release Tagging（RC / Release Tag 部署）
- Hotfix Patch Branch（僅於正式區有 bug 時使用）
流程總覽
| 動作 | Trigger | 部署環境 |
|---|---|---|
| Push 任意分支 | branch pipeline | Build & Test |
Merge → main | main pipeline | Deploy to DEV |
Tag vX.Y.Z-rcN | RC pipeline | Deploy to TEST/QAS |
Tag vX.Y.Z | Release pipeline | Deploy to PRD |
| Hotfix from Tag | hotfix pipeline | Build & Test |
Hotfix Tag vX.Y.Z-rcN | hotfix RC pipeline | Deploy TEST/QAS |
Hotfix Tag vX.Y.Z | hotfix release pipeline | Deploy PRD |
| Hotfix PR → main | merge pipeline | Sync 回主幹 |
這是哪種 Git Flow？
此流程屬於：
Trunk-Based Development + Tag-Driven Release + Hotfix Patch Branching
它不是傳統 GitFlow（沒有 develop / release 等長期分支）。 也不是 GitHub Flow（GitHub Flow 不使用 tag 來區分環境部署）。
這種設計的核心精神是：
- main 作為唯一長期分支
- feature/hotfix 分支存活極短
- 以 Tag 決定部署區域（RC → 測試、正式 Tag → PRD）
- 以自動化 pipeline 取代過去複雜的 release 分支
優點
- 分支數極少、邏輯簡單
- 自動化友善（CI/CD 不需要判斷太多狀況）
- 降低長期分支造成的版本漂移
- RC / Release tag 與部署環境精準綁定
- 不需要解釋 GitFlow 的 develop/release/hotfix 流程
- 更符合現代 DevOps 的迭代速度
⸻
是的，這是一種 trade-off。 在多專案、多人協作的情境下，要讓每位開發者都完整理解 GitFlow 的分支策略很不容易。 而且不同專案經常在同一平台上並行開發，要讓大家「正確地建立 develop、feature、release 分支」常會造成溝通成本、甚至操作混亂。
使用 Trunk-Based Development + Tag Release 的方式，分支少、規則簡單、部署行為明確，也更容易教育新同仁或跨專案團隊。
Git Flow 主流程（開發 → 測試 → 正式）
Flowchart
Hotfix 流程（正式區 BUG 修補）
當生產環境（PRD）發現 bug 時：
- 從對應的 正式版 tag（vX.Y.Z） checkout 出 hotfix branch
- 修正後打 RC Tag → 自動部署測試
- 測試驗證後打正式 Tag → 自動部署正式
- 最後 PR 回 main（保持主幹一致）
Flowchart（含 Hotfix）
Sequence Diagram
為什麼這種 Flow 適合現代 DevOps？
- 分支極少 → 減少 divergence
- tag 驅動部署 → 穩定可追溯
- 自動化清晰（DEV → TEST → PRD）
- hotfix 可快速響應正式環境
- main 永遠保持最新、穩定