Author：歪瑞古德小队-黄钰朝
git commit 的格式为：type(scope):subject
三个选项的含义如下：
| 选项 | 含义 |
|---|---|
| type | commit的类型（哪种类型的改动） |
| scope | 这次改动影响的范围（精确到影响哪个包） |
| subject | 具体改动的说明 |
其中包含的type的类型如下：
| 类型 | 说明 |
|---|---|
| feat | 增加新功能（feature） |
| fix | 修补bug |
| docs | 修改了文档（documentation） |
| style | 代码格式或注释变动（不影响代码运行的变动） |
| refactor | 重构（即不是新增功能，也不是修改bug的代码变动） |
| test | 增加测试 |
| chore | 构建过程或辅助工具的变动 |
示例：
| commit | 解释 |
|---|---|
| feat(service,controller):添加用户登陆的功能 | 这是增加功能的commit，代码改动出现在service和controller两个包 |
| fix(service):修复用户信息缺少昵称的问题 | 这是修复bug的commit，代码改动出现在service包 |
| docs(docs):修改了README中项目名称 | 这是修改文档的commit，文档改动出现在docs包 |
- master ：长期分支，一般用于管理对外发布版本，每个 commit 对一个 tag，也就是一个发布版本
- dev： 长期分支，一般用于作为日常开发汇总，即开发版的代码
- feature： 短期分支，一般用于一个新功能的开发
- hotfix： 短期分支 ，一般用于正式发布以后，出现 bug，需要创建一个分支，进行 bug 修补。
- release： 短期分支，一般用于发布正式版本之前（即合并到 master 分支之前），需要有的预发布的版本进行测试。release 分支在经历测试之后，测试确认验收，将会被合并的
新版本开发的流程包括以下部分：
- 新版本要开启一个feature分支
- 成员的从自己的分支发起pull request，经过审核人code review之后，合并到feature分支
- 当前版本开发完成，经过内测之后合并到dev分支，由dev发布开发版
- 开发版经过公测之后合并到mater分支，发布正式版
其中code review应当检查以下部分：
-
代码规范
-
基本语法和基本逻辑错误
-
业务逻辑的一些经验