git规范

分支规范

1. master 主分支
2. 生产环境分支。固定分支
3. master主分支始终保持稳定的可发布版本
4. 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主要负责人操作）
5. 合完master，打完tag（v1.1.1）才能进行发布
6. dev 开发分支
7. 测试环境分支。固定分支
8. 此分支包含：正在测试、等待测试的代码，属于不稳定代码分支
9. 由于 dev分支存在多种类型分支的合并（新功能开发、问题修复、代码重构），故，不能基于此分支创建任何类型的新分支，同时，也不能将此分支合并到其他分支
10. 原则上不允许直接在dev分支上进行功能开发，必须新建研发分支dev_{功能}_{研发人员首字母缩写}进行开发
11. dev_{功能}_{研发人员首字母缩写}分支完成后merge到dev分支发布测试
12. pre-release(uat)预发分支
13. 预发环境分支。固定分支
14. hot_fixed
15. 线上紧急修复分支，从master分支创建，仅仅适用于**生产线问题紧急修复**！！！！
16. 原则上不允许master以外的分支merge到该分支
17. 修复之后merge到dev分支发布测试，测试完成后merge到master分支发布生产
18. dev_{功能}_{研发人员首字母缩写}
19. 从master分支创建，用于新功能开发，每天下班前push提交到远程
20. 开发完成以后，merge到dev分支发布测试，测试完成后merge到master分支发布生产，并删除该分支 
21. 特别注意：发布完成的分支，及时删除

提交规范

类型	描述
doc	文档修改
feat	新增功能
fix	bug 修复
docs	文档更新
style	不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
refactor	重构代码(既没有新增功能，也没有修复 bug)
perf	性能, 体验优化
test	新增测试用例或是更新现有测试
build	主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
ci	主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle 等)的提交
chore	不属于以上类型的其他类，比如构建流程, 依赖管理
revert	回滚某个更早之前的提交

回退规范

由项目负责人负责回滚到具体commit hash 或具体tag