优缺点
主干开发：是指开发人员直接向主干（习惯上主干分支通常为：main或master）提交/推送代码。通常开发团队的成员1天至少一次地将代码提交到主干分支，在到达发布条件时，从主干拉出发布分支通常为（release），用于发布，若发现缺陷，直接在主干上修复，并根据需要cherry pick到对应版本的发布分支，
| 优点 | 缺点 |
|---|---|
| 分支模型简单高效，开发人员易于掌握不容易出现错误操作， | 基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关； |
| 避免了分支合并，冲突解决的困扰， | 自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈， |
| 随时拥有可发布的版本，有利于持续集成和持续交付 | 最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发CR，通过Peer Review后才能正式合入， |
| – | 最好有特性开关：主干开发频发合入主干的情况下，特性拆分的很小，可能是半成品特性，需要配套开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开 |
场景
现代Git实践更倾向于使用main作为默认分支名称以避免某些文化上的敏感性问题）开发适合以下几种场景：
小型项目：对于规模较小、开发周期短、团队成员少的项目，使用主干分支开发可以简化流程，提高开发效率。
快速迭代：在需要快速迭代和频繁发布的情况下，主干分支开发能够减少分支管理带来的开销，使得新功能能够更快地集成到产品中。
持续集成/持续部署（CI/CD）：主干分支开发非常适合与CI/CD流程结合使用。通过自动化测试和部署，可以确保主干上的代码始终是可用的，从而加速开发到部署的整个过程。
功能分支较少：如果项目中大部分工作都是直接在主干上进行，且功能分支较少，那么使用主干分支开发是合理的。这种情况下，团队成员可以更容易地保持对项目的整体了解，减少合并冲突的可能性。
高度协同的团队：对于高度协同、沟通顺畅的团队来说，主干分支开发可以促进团队成员之间的紧密合作。通过频繁的代码审查和交流，可以及时发现和解决问题，确保项目的顺利进行。
然而，需要注意的是，主干分支开发也要求团队成员具备较高的责任感和自律性，以确保代码的质量和稳定性。同时，对于大型项目或需要长期维护的项目来说，可能需要更复杂的分支管理策略来应对不同的开发需求和版本控制问题。因此，在选择是否使用主干分支开发时，需要根据项目的实际情况和团队的特点进行权衡。
