Git 工作流实战：从 GitFlow 到 Trunk-Based Development

GitFlow：经典但复杂

GitFlow 是最经典的 Git 工作流：

main (生产)
  └── develop (开发)
        ├── feature/* (功能分支)
        ├── release/* (发布分支)
        └── hotfix/* (热修复分支)

优点: 结构清晰，适合传统发布周期 缺点: 分支过多，合并复杂，不适合持续部署

GitHub Flow：简化版

main (随时可部署)
  └── feature-branch (PR → Review → Merge)

核心原则:

• main 分支永远可部署
• 功能从 main 创建分支
• 通过 Pull Request 合并
• 合并后立即部署

Trunk-Based Development：现代首选

trunk/main
  └── 短命分支 (< 1 天) 或 直接提交

关键实践:

1. 小步提交: 每次提交都是完整功能的一小部分
2. 功能开关: 用 Feature Flag 控制未完成功能
3. 持续集成: 每次提交都触发自动化测试

工作流对比

工作流	适用场景	复杂度
GitFlow	传统发布、多版本维护	高
GitHub Flow	SaaS、持续部署	中
Trunk-Based	敏捷团队、CI/CD 成熟	低

实践建议

• 小团队/初创: GitHub Flow 或 Trunk-Based
• 企业/多版本: GitFlow 或简化版
• 关键: 选择适合团队的，然后严格执行

总结

没有最好的工作流，只有最适合的。关键是团队达成共识并严格执行。