Git分支策略选错了，团队协作全是坑

三个人的项目和三十人的项目，分支策略肯定不一样。选错了要么频繁冲突，要么发版混乱。

Git Flow：适合有固定发版节奏的项目

main分支只放稳定版本，develop分支是开发主线。功能开发从develop拉feature分支，完成后合并回develop。要发版时从develop拉release分支，测试通过后同时合并到main和develop。hotfix从main直接拉分支修完合并回去。

这套流程规范但重，适合版本发布有固定周期的传统项目。小团队用会觉得来回合并太累。

GitHub Flow：适合持续部署

只有一个main分支，所有开发都从main拉分支，提PR合并回main，合并后自动部署。没有release分支，没有develop分支，流程极其简单。适合Web应用、SaaS这类随时可以发版的项目。

缺点是没有发版管理，需要靠tag和CI来追踪哪个版本在线上。

Trunk Based：适合大团队

所有人直接往main分支提交（或用非常短命的分支），依赖feature flag控制功能上线。听起来危险，但Google、Facebook都是这么干的。核心是强大的CI和自动化测试保证main永远可用。

普通团队不太敢用，因为对自动化测试覆盖率要求极高。

怎么选

5人以下用GitHub Flow，简单高效。有固定发版周期用Git Flow。20人以上、CI成熟、追求快速迭代用Trunk Based。别为了规范而规范——分支策略是为团队服务的，不是团队为策略服务。