前因，最近发布生产环境的时候，出现了功能丢失的情况，上个版本更新的功能缺失了，检查后发现打包的分支出现了问题。故整理了一份基于Git开发的分支命名规范
生产分支
master，只能合并release的代码，或者从产品侧合并代码，不能直接提交代码到这个分支，只能从release合并。
生产验证通过后，其他所有分支合并master的代码。
测试分支
release，不能直接提交代码到这个分支，合并下个版本需要发布的分支。
如果需要长期保留的预发布分支，则新建分支release_xxx_xxx。
开发分支
develop，不能直接在该分支上直接提交代码，拥有最新功能的分支。
功能分支
命令规范
功能描述_更新时间。例如：todo_20210501。
开发新功能从master检出分支，开发完自测完成合并到develop，需要下个版本发布则合并到release，待上线后删除当前分支。建议每天上班前合并master的代码。
bug分支
命令规范
fixbug_bug描述_更新时间，例如：fixbug_todoproblem_20210501
生产环境的bug，一般从master检出，修复完合并到release，待上线后删除当前分支。
功能分支未上生产产生的bug，继续在原来分支上修复。
注释规范
提交代码一定要有注释，没有注释的代码不能提交
例如
姓名xxx：待办功能开发
