主流方案
主干开发(TBD)
开发者在一个master分支中对代码进行协作，除了发布分支外没有其他开发分支
每次集成冲突少效率高<br>
能享受持续交付带来的所有好处
无需在分支之间做切换
容易出现“一粒老鼠屎坏了一锅粥”的灾难<br>
要借助特性切换等机制保证线上运行的正确性，这会引入新的问题<br>
特性分支开发
Git Flow
分为Master、Hottfix、Release、Develop、Feature 5个分支
完善的发布流程<br>
流程太繁琐，需要维护很多分支<br>
GitHub Flow
master 分支时常保持可以部署的状态
新的作业时要从master 创建新的分支
代码完成后通过GitHub提交pull request；通过自动化测试和代码审查后，合并到master分支。再从master部署到生产环境
以部署为中心的开发模式，通过简单的功能和规则，持续且高速和安全地进行部署<br>
依赖GitHub和公司的部署流程<br>
GitLab Flow
带生产分支
无法控制准确的发布时间，但又要求不停集成
需要创建一个production分支来放置发布的代码
带环境分支
要求所有代码都在逐个环境中测试通过
需要为不同的环境建立不同的分支
带发布分支
用户对外界发布软件的项目，同时需要维护多个发布版本
尽可能晚的从master拉取发布分支
Bug的修改应先合并到master，然后cherry pick到release分支
分支选择策略
主干开发
<ul><li>开发团队系统设计和开发能力强<br></li><li>有一套有效的特性切换实施机制，保证上线后无需修改代码就能修改系统行为<br></li><li>需要快速迭代，想获得CI/CD所有好处<br></li></ul>
Git Flow
<ul><li>不具备主干开发能力<br></li><li>有预定的发布周期<br></li><li>需要执行严格的发布流程<br></li></ul>
GitHub Flow
<ul><li>不具备主干开发能力<br></li><li>随时集成随时发布<br></li><li>分支集成后经过代码评审和自动化测试，就可以立即发布应用<br></li></ul>
GitLab Flow(带生产分支)
<ul><li>不具备主干开发能力<br></li><li>无法控制准确的发布时间，但又要求不停集成<br></li></ul>
GitLab Flow(带环境分支)
<ul><li>不具备主干开发能力<br></li><li>需要逐个通过各个测试环境验证</li></ul>
GitLab Flow(带发布分支)
<ul><li>不具备主干开发能力<br></li><li>需要对外发布和维护不同版本</li></ul>
