前言
上个月公司来了位前端大佬，给我们团队制订了一些技术方面的规范，其中有一项是关于在Git上提交代码写Commit Message的一些规范，开始我还觉得多此一举，看了许多大型项目的commit记录之后，才知道这个规范算是行业里的标准。
先来看看我的CodeStudy项目里是写的什么Commit Message
再看看尤雨溪大佬的作品Vue框架的Commit Message
果然一个规范的Commit Message真的能让人眼前一亮，可以快速了解到该commit的内容和涉及的功能模块，下面说说规范化Commit Message能带来什么好处。
规范化的好处
- 便于程序员对提交历史进行追溯，了解发生了什么情况。
- 一旦约束了
Commit Message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰 - 格式化的
Commit Message才可以用于自动化输出Change log
Git提交规范
<type>(<scope>):<subject>
<body>
<footer>| 名称 | 作用 |
|---|---|
| type | 用于说明 Git Commit 的类别，只允许使用下表的标识 |
| scope | 用于说明 Commit 影响的范围，比如数据层、控制层、视图层等 |
| subject | Commit 目的的简短描述，一般不超过50个字符 |
| body | 可忽略，可多行，详细的描述，与header之间空一行 |
| footer | 可忽略，一般用于不兼容更新或关闭issue，与body之间空一行 |
| 类型 | 描述 |
|---|---|
| sync | 同步主线或分支的bug |
| merge | 代码合并 |
| revert | 回滚到上一个版本 |
| chore | 构建过程或辅助工具的变动 |
| test | 增加软件测试 |
| perf | 优化相关，比如提升性能、体验 |
| refactor | 重构，既不是新增功能，也不是修改bug的代码变动 |
| style | 格式，不影响代码运行的变动 |
| docs | 文档撰写或更新 |
| fix / to | 修复bug，可以是QA发现的bug，也可以是研发自己发现的bug |
| feat | 新功能（feature） |
插件推荐
在VS Code上面强烈推荐Commit Message Editor插件，可以快速生成Git Commit Message
