【前言】
目前入职新公司一个多月，上级让我带领前端小组，其实入职没多久就发觉前端代码质量很差，提升代码质量一直都是个艰难而持续的过程，从git规范，到代码质量规范缺一不可，那么先从git规范开始。
【分支概要】
| 分支名称 | 分支说明 |
|---|---|
| master | 生产分支，不能直接在此分支开发 |
| feature | 功能分支，基于master分支创建的迭代分支 |
| release | 测试分支，feature分支开发完成，合并到这个分支 |
| hotfix | 修复分支，基于master分支创建 |
【基本规则】
master分支
不能直接开发，只能其他分支合并进来，不能将其合并至其他分支
命名规则：固定master
合并规则：
- 迭代开发：git merge feat-xxx
- 修复线上：git merge fix-xxx
注意：master只能合并feature、hotfix分支
其他规则：
- 每一次合并完成后，需要打tag，方便回滚
- tag命名规则：tag-feat-xxx_mmdd或tag-fix-xxx_mmdd，mmdd为当前月、日，例如tag-feat-order_1111
feature分支
每一次的迭代需求产生的临时分支，待开发完成、测试完成并发布上线后，删除
命名规则：feat-xxx，例如feat-order
创建规则：git checkout -b feat-xxx origin master
注意：开发完成后需合并至release分支
release分支
每一次的feature分支合并到此分支，不能将release合并至其他分支，用来部署开发、测试环境。
命名规则：固定release
合并规则：
- 迭代开发：git merge feat-xxx
- 修复线上：git merge fix-xxx
注意：release只能合并feature、hotfix分支
hotfix分支
修复线上bug，修复完成需合并到release、master分支
命名规则：fix-xxx，例如fix-order
创建规则：git checkout -b fix-xxx origin master
【其他规范】
commit提交信息，遵循：< type> explain 规范
type参照表
| type | 说明 |
|---|---|
| feat | 功能 |
| fix | 修复某个bug |
| docs | 文档或注释 |
| style | 样式相关 |
| refactor | 重构 |
| test | 测试数据、模拟数据 |
| other | 其他 |
举几个栗子：
feat 多集配中心接口联调
fix 下拉回显修复
style 弹窗样式修改
refactor 导出逻辑重构
