上个月公司来了位前端大佬，给我们团队制订了一些技术方面的规范，其中有一项是关于在 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。
