Git 工作流：團隊怎麼協作？
Git Flow vs Trunk-Based
Git Flow
main ─────────────────────────────────── (正式版)
↕
develop ──┬──┬──┬──┬──┬──────────────── (開發版)
│ │ │ │ │
feature/ │ │ │ │ │
login ────┘ │ │ │ │
feature/ │ │ │ │
cart ────────┘ │ │ │
release/ │ │ │
v1.0 ──────────┘ │ │
hotfix/ │ │
urgent ───────────┘ │
feature/ │
search ──────────────┘
適合：發版節奏固定、大型團隊
缺點：分支太多、合併複雜、容易衝突
Trunk-Based（主流推薦）
main ─┬─┬─┬─┬─┬─┬─┬─┬─ (每天都可部署)
│ │ │ │ │ │ │ │
小 小 小 小 小 小 小 小
PR PR PR PR PR PR PR PR
適合：CI/CD 成熟、小型敏捷團隊
原則：分支生命短（< 1 天）、頻繁合併到 main
優點：衝突少、部署快、code review 範圍小
Rebase vs Merge
Merge：保留完整歷史
A─B─C─────F (main)
\ /
D─E (feature)
→ 多一個合併 commit（F），歷史有分岔
Rebase：線性歷史
A─B─C─D'─E' (main)
→ feature 的 commit 被「重新播放」在 main 之後
→ 歷史乾淨，但改寫了 commit hash
| Merge | Rebase | |
|---|---|---|
| 歷史 | 保留分支記錄 | 線性乾淨 |
| 安全性 | ✅ 不改寫歷史 | ⚠️ 改寫 commit hash |
| 適合 | 多人協作的 feature branch | 個人 feature branch 整理 |
| 衝突 | 一次解決 | 可能要逐 commit 解決 |
金規：只 rebase 自己的 branch，不要 rebase 已經 push 的公共 branch。
Code Review 文化
好的 PR：
- 小（< 400 行）
- 一個 PR 做一件事
- 有清楚的描述（為什麼改、改了什麼）
- 自己先 review 一次
壞的 PR：
- 2000 行改動，看不完
- 標題寫「update」
- 混合了 feature + refactor + bug fix