三种 Git 分支模型怎么选：GitFlow、Trunk-Based 与发布分支

GitFlow：重，但边界清晰

master、develop、feature、release、hotfix 五类分支，适合发布周期长、需要并行维护多个版本的场景，比如客户端软件。代价是合并路径复杂，长期存在的 develop 分支容易和主干偏离，集成问题被推迟到最后才暴露。

Trunk-Based：轻，但要求高

所有人往 main 提交，功能用开关控制发布。它把集成问题变成每天都要面对的小问题，配合完善的自动化测试和 feature flag，发布频率可以很高。前提是团队必须有可靠的测试网和快速回滚能力，否则主干会长期不可发布。

发布分支：折中方案

主干持续开发，发版时从主干切一条 release 分支，只接受修复类提交。这样既保持了主干的流动性，又给了测试和灰度一个稳定的基线。多数中小团队的实际选择落在这里。

怎么选：三个问题

• 需要同时维护几个线上版本？超过两个，倾向 GitFlow。
• 每天能发几次？能发多次且测试可靠，倾向 Trunk-Based。
• 回滚是切版本还是打补丁？切版本用 Trunk-Based 更顺。

落地建议

不要一次换全套流程。先把发布分支规范起来，再逐步缩短分支生命周期，最后才考虑取消长期分支。流程改动带来的成本，往往比工具本身更大。