前言

分支是指在代码版本控制系统中创建的一个独立的分支，通常用于开发新功能或修复bug。分支通常是暂时的，它们的目的是在开发过程中保持代码库的稳定性。

对于这个命题，网上各种说法都有，各公司也是有自己的发版流程，标准不一。

几种情况

高频次发布

一般情况下，对频繁更新的场景，用分支更新更合适，发布完再合master。这个模式快，用发布分支代替tag，上线后再合并的思路。多分支发布还用于A/B测试场景，保留哪个还不好说呢，干脆先不合，等选定最终版本以后再合。

固定节奏发布

对于产品发布这样有固定节奏的情况，测试完就可以合主干。为了定版，找某个合并点打个标签，就可发布了，打标签不要求是最新的版本。这个模式要求高，合并的都是发布计划中的，且经过完整测试的需求，适合大团队协同。

灰度折中

当然，git只是一个工具，可以按照自己的项目的模式来用，没有什么对错之分。Google现在都推荐主干开发，和之前特性分支完全不一样，而且思路完全是相悖的。

目前很多项目也是用主干开发的模式，发版直接拉release分支，但是会保留3天的灰度时间，灰度期间在release测出问题还可以在主干修了后cherrypick到release分支。

小结

使用分支、tag或者master，都是可用的，具体看公司技术团队的选择。

相比之下，我个人比较倾向使用tag。tag是指将代码库的某个特定版本标记为发布版本。标记为tag的版本通常是一个经过测试和验证的稳定版本，可以在生产环境中使用。标记为tag的版本不会随着新的开发而改变，是固定且可追溯的。