🌿 Git分支策略
Git分支策略对比与选择指南，帮助你选择适合团队的分支模型
简单GitHub Flow
最简单的分支策略，适合持续部署的Web应用。只有一个长期分支 main，所有开发在 feature 分支进行，通过 Pull Request 合并。
main← 随时可部署的生产分支
├──
feature/*← 功能分支，完成后PR合并到main├──
hotfix/*← 紧急修复，直接合并到main✅ 优点
- 简单易懂，学习成本低
- 适合持续部署
- PR审查保证质量
❌ 缺点
- 不适合需要多版本维护的项目
- 缺乏发布管理
🎯 适用场景
- SaaS产品
- 持续部署的Web应用
- 小团队快速迭代
复杂Git Flow
经典的分支模型，适合有明确发布周期的项目。包含5种长期/短期分支，流程严格但完善。
main← 生产分支，只合并release和hotfix
├──
develop← 开发主分支，集成所有功能│ ├──
feature/*← 功能分支，从develop创建│ ├──
release/*← 发布分支，从develop创建，合并到main和develop└──
hotfix/*← 紧急修复，从main创建，合并到main和develop✅ 优点
- 清晰的发布流程
- 支持多版本并行
- 紧急修复不影响开发
❌ 缺点
- 分支复杂，学习成本高
- 合并冲突频繁
- 不适合持续部署
🎯 适用场景
- 有版本号的产品
- 需要维护多个版本
- 中大型团队
推荐GitLab Flow
介于GitHub Flow和Git Flow之间的折中方案，引入环境分支概念，兼顾简洁和规范。
main← 代码主分支
├──
staging← 预发布环境├──
production← 生产环境├──
feature/*← 功能分支✅ 优点
- 环境分支对应部署环境
- 比Git Flow简单
- 支持多环境部署
❌ 缺点
- 需要维护环境分支
- 上游合并可能延迟
🎯 适用场景
- 多环境部署项目
- 需要预发布验证
- 中型团队
简单Trunk-Based Development
所有开发者都在主干(main/trunk)上提交，使用Feature Flag控制未完成功能。适合CI/CD成熟度高的团队。
main (trunk)← 所有开发在此进行
├──
short-lived/*← 短命分支(1-2天)，快速合并回main✅ 优点
- 无合并地狱
- 持续集成
- 快速反馈
❌ 缺点
- 需要Feature Flag
- 需要完善的CI/CD
- 不适合新手团队
🎯 适用场景
- Google/Facebook级工程
- 高成熟度CI/CD
- 经验丰富的团队