Git 工作流选型：Trunk-Based 还是 GitFlow？
选错 Git 工作流，轻则合并冲突不断，重则发布流程卡死。我在两家公司经历过两种工作流的切换，说说真实的感受。
GitFlow
BASH
main ●───────●──────────●── (生产)
│ │ │
develop ●──●──●─●──●──●──●── (开发)
│ │ │ │
feature/* ●──● ●──● (功能分支)
│
release/* ●──● (发布分支)
│
hotfix/* ●──● (热修复)优点：
- 分支职责清晰
- 适合有固定发布周期的团队
- 多人并行开发不会互相干扰
缺点：
- 分支太多，合并复杂
- develop 和 main 经常不同步
- 不适合持续部署
适合场景：传统软件、App 发版、有 QA 团队
Trunk-Based Development
BASH
main ●──●──●──●──●──●──●── (主干)
│ │ │ │
分支 ● ● ● ● (短生命期分支，<2天)优点：
- 代码永远是最新的
- 合并冲突少
- 天然支持 CI/CD
缺点：
- 要求团队纪律性高
- 需要 feature flag 配合
- 代码评审要及时
适合场景：SaaS、持续部署、小团队
我们踩过的坑
GitFlow 的坑
BASH
# 经典灾难场景：hotfix 合并顺序搞错
git checkout main
git merge hotfix/urgent-fix
git checkout develop
git merge hotfix/urgent-fix # 忘记这步，develop 和 main 分叉了Trunk-Based 的坑
BASH
# 大功能直接提交到 main，破坏性变更
git checkout -b huge-feature
# ... 两周后 ...
git checkout main
git merge huge-feature # 300 个冲突正确做法：
BASH
# 大功能用 feature flag + 小步提交
# 1. 先提交接口定义
# 2. 再提交实现（feature flag 关闭）
# 3. 逐步开启
const useNewFeature = featureFlag('new-checkout')
if (useNewFeature) {
return <NewCheckout />
}
return <OldCheckout />我的选择建议
| 团队规模 | 发布频率 | 推荐工作流 |
|---------|---------|-----------|
| 1-3人 | 每天 | Trunk-Based |
| 4-10人 | 每周 | Trunk-Based + 短分支 |
| 10+人 | 每两周 | GitFlow |
| 任何规模 | 持续部署 | Trunk-Based |
总结：小团队用 Trunk-Based，大团队有固定发版周期用 GitFlow。关键是选一个，然后全团队严格执行。
读者评论 4