git commit是日常工作中使用率极高的一个命令，但是根据我从业5年的经验来看，大多数人在用git commit命令时都很粗糙，比如git commit -m 后跟的message是五花八门，有用中文的，有用英文的，甚至还有直接跟111的，这些commit，不要说接手的人很难看懂，时间久了估计连提交人自己都忘记咋回事了。
本文我就带大家了解下git commit有哪些规范及高级用法。
咱们先了解一下规范的commit能带来哪些好处
- 能够让自己和协同自己开发的人员清晰的知道每个commit 的变更内容，方便快速浏览变更历史
- 可以基于commit的信息进行过滤查找，比如之查找某个版本新增的功能:
git log --oneline --grep "^feat|^fix|^perf"- 可以基于规范化的commit生成Change Log
- 可以根据某些类型的commit 触发构建或者发布流程，比如当type类型为feat、fix时我们才触发CI流程
总之，一个好的commit可以使commit的可读性更好，并且可以实现自动化，那究竟该如何写一个易读的commit呢？
Commit 的规范
commit的规范其实在开源社区中已经很成熟了，大家可以看看GitHub上start数量比较多的开源项目，看下别人的commit信息都是怎么规范的。
这里我们以Docker的commit记录来举例：
请大家注意我在图中圈红的地方，可以看到每一个commit的最前面，都有一个类似于本次commit类型的说明，是新功能发布（feat），还是文档更新（chore），又或是bug修复（fixbug），都会有一个对应的标识放在commit的最前边，熟悉规范的同事一眼就能看出哪些commit对他来说是有用的。
那我们应该怎么写出规范的commit呢？
我们先来说commit的类型：
| 类型 | 说明 |
| feat | 新增功能 |
| fix | bug修复 |
| perf | 性能优化 |
| style | 代码格式化 |
| test | 测试用例的新增或更新 |
| ci | 部署相关文件的改动 |
| docs | 文档类的变动 |
| chore | 其他类型 |
| refactor | 代码简化、删除冗余代码等 |
我每次在commit的时候，在commit信息前边加上这些类型标识，是不是一下子就清晰起来了，我们在进行git log查询的时候也不需要一个一个去翻了，可以直接根据type筛选出我们最需要的commit记录，效率噶一下就上来了。
