正常开发流程
管理人员：有新需求，创建master分支，上传基础代码，已有产品需求，以当前产品上线功能作为master分支
管理人员：当接收到正常的业务需求时，约定一个大的发布版本，由管理人员在master分支基础上创建develop分支
开发人员：以develop分支为基础，创建一个功能模块开发分支，分支名称为“feature-功能编号-开发人员姓名简拼“，例如feature-cloud-21-wangrz”。所有开发过程的commit message需要填写具体的开发内容。
开发人员：开发及单元测试工作完成后创建merge request合并到develop分支，合并请求消息同样需要复制提交的内容描述以及具体的开发内容。
开发人员：单元工作基于合并后的develop分支代码进行，如果这个发布版本所有任务全部自测通过后
管理人员：基于测试通过的develop分支创建一个release分支，分支名称为“release-版本号”，如“release-orilogV1.0”，测试人员基于release分支进行测试。
测试人员：继续在新建的release分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到develop分支；如果验证通过则准备生产上线，
管理人员：生产上线时将release代码合并到master分支，并打tag，tag名称为“tag-版本号”，从master打包上线
紧急开发流程
管理人员：当发现线上bug需要紧急修复时，需要以master分支为基准创建一个hotfix分支，并为分支创建相应开发人员权限
开发人员：拉取分支，bug修复代码直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。测试人员直接在hotfix分支测试
测试人员：测试人员直接在hotfix分支测试
开发人员：测试通过后，开发人员同时请求合并到master分支和develop分支，合并请求消息需要复制任务描述以及具体的开发内容
管理人员：生产上线时将hotfix代码合并到master分支，并打tag，tag名称为“tag-版本号-功能编号”，从master打包上线。
总体说明
管理人员与开发人员长期的使用的分支有两个master分支和develop 分支，其他的辅助分支hotfix分支紧急bug修复时使用，feature分支为功能模块开发分支，作为开发人员可选分支，只要保证develop分支不冲突，本身代码管理清晰即可。release分支作为测试分支，其生命周期在合并到develop或master上之后就基本结束，所以大家要养成良好的习惯，在分支生命周期结束之后尽快删除掉，以免堆积太多的分支而导致混乱；
开发过程中要勤提交、勤合并，原则上一些方法级别、类级别或单元测试级别的修改可以发起一次提交，提交的commit message写明工作的内容，一个feature或bug的自测完成可以发起一次merge request，merge request的message内容要复制功能任务的描述以及具体的开发工作内容描述，切勿堆积很大的工作量才发起合并
