分支模型
主干分支
Master ：随时可供在生产环境中部署的代码，建议伴有标签（TAG）
Develop：每天需要提交和合并的代码，功能逐渐完成的代码开发分支
辅助分支
Feature：新功能分支，辅助develop分支。主要用于实验性且效果不好的代码变更。或者用于项目组新成员接手开发新功能等。分支可以合并到develop分支，或者直接丢弃。
命名规范：feature-*
Release分支：当基本版本完成，准备提交上线时的分支，本分支可以做小BUG的修复。成功通过测试后，必须合并到Master分支，并记录标签（Tag），如果有BUGfix，则还需合并到Develop分支。此版本的作用是项目二期可以继续在develop分支开始开发。
命名规范：release-*
Hotfix分支: 对于线上版本（Master分支）的BUG修改的辅助分支，必须合并回master分支和develop分支。
命名惯例：hotfix-*
Feature分支上的持续集成
开发者在feature分支上push代码后执行， 包括：代码质量检查， 代码静态扫描，单元测试，程序编译。
如果CI失败，feature分支上的相关程序员需要修复相关的问题，如果上次提交的pipeline没有执行完成，开发者提交了新的代码，则老的pipeline停止， 新的pipeline包括了上次的所有代码提交的持续集成检查。
如果CI成功，则可以发次MR进行代码review。 代码review的时候，review人员可以参考Feature分支上的CI结果。
Develop分支上的持续集成
CI成功后， Feature分支被合并到Develop分支，develop分支上的每个节点（merge request合并节点）会触发一个持续集成pipeline，包括：单元测试，程序编译，接口测试，动态安全扫描，集成测试，打包
如果CI失败，则所有人应该分析错误， 相关人员应该拉取一个修复分支（相当于feature分支），进行修复并提交代码，合并到develop分支，直到develop分支ci变绿，变绿之前，所有人不能合并其他任何feature分支。
如果CI成功，则相关的节点会有相关的发布包被push到二进制仓库，并且打上 “snapshot-commit号“标签。
CI成功后，相关的二进制包会被部署到本sprint的集成测试环境，保证本迭代的测试环境是最新的可执行的代码。
Release/Hotfix分支上的持续发布
在Release分支创建后，CD pipeline把当前的commit对应的编译包升级为测试包，打上 “test-版本号-commit号", 并部署到验证测试环境。
用户验证如果发现bug，则release分支上创建feature分支（针对bug）， 修复bug，提交（触发Feature分支CI）， MR合并到Developer（触发develop分支CI），Cherry pick到Release分支， 触发Release分支CD。 当前的commit对应的编译包升级为测试包，打上 “test-版本号-commit号", 并部署到验证测试环境。
如果Release分支测试成功（这里默认需要手动测试），release分支需要通过MR review，合并到Master分支并打版本Tag。Review需要参考测试提交的测试报告。
Master分支上的持续发布
Master分支合并成功后，CD pipeline 把当前的commit号对应的包的package升级为生产环境，并发布到生产环境。