引言

光裝了 Git 不夠，沒有分支規範的團隊遲早會踩到「main 被直接推壞」或「三個人同時改同一支分支」的坑。這篇整理一套以 Gitflow 為基礎的分支模型，適合中小型專案直接套用。

1. 主要分支

1.1 主分支 (main)

主分支代表產品的穩定版本，任何時候都應該可以直接部署到正式環境。

  • 用途：對應正式環境的可部署版本
  • 規則：禁止直接在 main 分支上開發，所有變更必須經過 PR 審查

每次合併到 main 的程式碼都應該通過完整測試，不能引入未知的不穩定因素。

1.2 開發分支 (develop)

develop 是日常開發的整合中心，從 main 建出來，最終穩定後再合回 main。

  • 用途：整合各功能分支的開發成果
  • 特點：包含最新的開發進度，相對不穩定
  • 規則：功能與修復都先進 develop，確認穩定後才往 main 合

2. 支援性分支

2.1 功能分支 (feature)

  • 命名規則：feature/功能名稱（例如：feature/user-authentication）
  • 來源：從 develop 建立
  • 合併目標：完成後合回 develop

每個新功能都應該有自己的 feature 分支，避免互相干擾。開發完成後透過 Pull Request 合回 develop：

1
2
3
4
5
git checkout -b feature/user-authentication develop
# 開發新功能
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

2.2 發布分支 (release)

  • 命名規則：release/版本號（例如：release/1.2.0）
  • 來源：從 develop 建立
  • 合併目標：完成後同時合到 main 和 develop

release 分支用來做發布前的最後準備——跑測試、修小 bug、更新版本號。這段時間 develop 可以繼續接新功能，互不影響。確認沒問題後同時合進 main 和 develop，並在 main 打 tag 標記版本。

2.3 熱修復分支 (hotfix)

  • 命名規則：hotfix/問題描述（例如：hotfix/login-crash）
  • 來源：從 main 建立
  • 合併目標：完成後同時合到 main 和 develop

正式環境出緊急問題時，不能等 develop 穩定，直接從 main 開 hotfix 分支，修完立刻合回 main 和 develop。

3. 工作流程

典型的開發流程：

  1. 從 develop 建立 feature 分支
  2. 在 feature 分支上開發與測試
  3. 完成後透過 Pull Request 合回 develop
  4. 準備發布時從 develop 建立 release 分支
  5. 在 release 分支做最後測試與修正
  6. 發布完成後將 release 同時合進 main 和 develop，並在 main 打版本 tag
  7. 遇到正式環境緊急問題時，從 main 開 hotfix 分支處理

實際操作範例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 開始新功能開發
git checkout -b feature/shopping-cart develop

# 開發完成，合回 develop
git checkout develop
git merge --no-ff feature/shopping-cart
git push origin develop

# 準備發布
git checkout -b release/1.0.0 develop

# 最後的調整
git commit -am "Bump version number to 1.0.0"

# 完成發布，合進 main 和 develop
git checkout main
git merge --no-ff release/1.0.0
git push origin main

git checkout develop
git merge --no-ff release/1.0.0
git push origin develop

# 標記發布版本
git tag -a 1.0.0 -m "Version 1.0.0" main
git push origin --tags

# 刪除 release 分支
git branch -d release/1.0.0

4. 最佳實踐

4.1 小步提交

頻繁提交、每次只做一件事。這樣合併衝突的範圍小，出問題時也更容易找到是哪一步出的包。

4.2 清楚的提交訊息

格式統一，讓 git log 變得可讀。提交訊息要說清楚「做了什麼」，有必要時補上「為什麼這樣做」：

1
2
3
4
5
feat: 加入購物車功能

- 實作新增商品到購物車
- 實作從購物車移除商品
- 計算購物車總價

4.3 定期同步上游

開 feature 分支開了一週，develop 已經往前走很多步。定期把 develop 的更新 merge 進來，避免最後合併時一次爆大量衝突。

4.4 透過 PR 做程式碼審查

Pull Request 不只是合併的入口，也是讓隊友看程式碼、提早抓問題的機會。比起事後 debug，PR 的成本低很多。

4.5 CI/CD 自動化測試

每次 push 或 PR 都自動跑測試，不要靠人工記得。配好 CI，把「這段有沒有壞東西」的問題交給機器回答。

5. 工具

5.1 git-flow

git-flow 是 Vincent Driessen 開發的 Git 擴充工具，直接把這套分支模型包成指令（git flow feature start、git flow release finish 等），不用每次手動打 checkout 和 merge。

5.2 SourceTree

SourceTree 提供圖形介面，可以視覺化呈現分支結構，對不熟悉 CLI 的成員比較友善，也內建 git-flow 支援。

5.3 GitHub Flow

如果專案走持續部署、沒有明確的版本號概念，GitHub Flow 是更輕量的選擇：只有 main 和 feature 分支，feature 完成就合進 main 直接上線。架構比 Gitflow 簡單，適合快速迭代的小團隊。

結論

分支規範的核心只有一條：讓 main 隨時可以部署。其他的 develop、feature、release、hotfix 都是圍繞這個目標設計的保護層。

規範定好之後，團隊裡每個人都要照著走——工具再好，只有一半人遵守效果也會打折。