业内实践
　　git flow

　　固定远程分支：
　　master分支：主分支，和生产环境一致，存放已发布完成的版本
　　develop分支：主开发分支，用于合并功能分支，维护公共的新代码');" target="_self">代码
　　临时远程分支：
　　release分支：预发分支，发布时基于Develop分支创建一个Release分支，完成Release后，我们合并到master和develop分支
　　feature分支：功能分支，每个功能对应的分支，合并到develop分支和release分支后删除
　　hotfix分支：bug修复分支，后合并到develop和master分支后删除
　　优点：
　　清晰明了，每个分支都有都自己的作用，有工具或插件帮助操作者使用此流程。
　　缺点：
　　更加适合于按版本发布的项目，不太适合持续发布。有的服务更期望代码变动发布一次，每次发布需要合并develop、release、master三个分支。
　　github flow

　　如图，githubflow非常简单，只有一个固定的远程分支marter。每个研发人员fork项目后，在本地用功能分支开发，开发完成后提交PR请求合并master分支。
　　PR请求通过后，合并至master分支并部署。master分支代表可以随时上线的版本，并且可以通过持续发布系统，无限发布到生产环境。
　　但有些时候，PR被合并了之后我们可能也不会立刻发布到生产环境，久而久之，生产环境会落后master。
　　综合gitflow和githubflow的优缺点，在githubflow的基础上，增加一个production分支，用来标识目前已上线的版本。
　　配置流程

　　项目管理员创建gitlab仓库，创建并保护master分支，设立相关权限
　　研发人员fork项目，生成自己的fork库
　　研发人员clone自己的fork库至本地
　　研发人员在本地新建功能分支，并提交至本地分支，也可以push功能分支至远程fork库备份
　　研发人员定期与远程主干分支同步
　　研发人员推送至自己的fork库
　　不需要测试人员测试时:
　　研发人员直接发起PR请求合并个人远程仓库的开发分支至项目远程仓库的master分支
　　CI自动执行代码静态检查和单元测试
　　项目管理员审核PR，合并请求完成开发流程
　　需要测试人员测试时:
　　研发人员通知项目管理员在项目远程分支中创建功能分支，研发人员发起PR请求合并个人远程仓库的开发分支至项目远程仓库的对应分支
　　CI自动执行代码静态检查和单元测试
　　项目管理员审核PR，合并至项目库的远程功能分支
　　测试人员拉取功能分支测试
　　测试人员提出PR请求，合并远程功能分支至master分支
　　CI自动执行单元测试
　　项目管理员审核PR，合并请求完成开发流程
　　项目管理员在发布平台选择响应的master提交进行发布，发布后自动对master标记tag
　　Git commit日志规范
　　gitcheckout新分支时，分支名采用feature_标题_erp#、bugfix_标题_erp#、refactor_标题_erp#
　　如：feature_batch_save_product_12345
　　gitcommit时提交日志规范如下：
<type>:<subject>
　　<body>　　
　　type枚举：
　　feat新增功能
　　fix修复bug
　　docs修改了文档、readme
　　style不改变代码逻辑，仅修改代码样式
　　refactor非功能性重构
　　test测试用例
　　subject:描述主要变更内容
　　body:主体内容，更详细的说明文本，如erp地址等，可以为空
　　Code Review
　　提交CodeReview之前要做什么？
　　准备或者提交相关需求文档以备审查者询问
　　编写符合规范的代码和合适的注释
　　考虑代码是否有重构的可能
　　单元测试全部通过，测试覆盖率达标
　　如何Code Review？
　　了解需求：这个提交是为了解决什么问题，是需求单、BUG修复、还是代码重构，
　　如果不明确，需要及时和代码作者沟通和讨论
　　检查代码业务逻辑是否符合需求
　　代码是否符合相关代码规范
　　确认是否有更好的方式方法重构代码
　　检查单元测试用例是否考虑全面
　　如果代码没有问题，也写上类似GOODJOB之类的评论
　　Code Review之后可以做什么？
　　对于代码审查人表示感谢
　　如果代码审查没有通过，不要往心里去，审查的是代码，不是你
　　尝试对每一个评论做出回复
　　等待合并分支，等待持续集成告诉你全部通过
　　项目结构规约
　　-doc文档文件夹，用来存放概要、详设、API等文档资料
　　-src程序源码文件夹，用来存放源码
　　-db数据库文件夹，用来存放可执行的数据库相关变更DDL脚本文件，如V1__init.sql，V2__feature_batch_save_product_12345.sql
　　-deploy(可选)用来存放部署相关文件，如shell脚本等
　　-..按项目自由配置
　　README.md项目说明
　　Dockerfile