Commit 消息 —— 也就是 Commit Message —— 在使用 Git 作为版本管理工具的时候对它绝对不陌生。一般来说，commit 消息清晰明了，可以说明本次提交的目的，具体做了什么操作，在日后回顾的时候非常有用，Git 也强制每次提交都要提供消息。
但是在日常开发特别是小组作业中，大家的提交消息千奇百怪也十分正常；你觉得你的提交消息已经够抽象了，但是总能找到比你更抽象的；中英文混合使用、fix bug这种说了和没说一样的笼统的消息也层出不穷，这就导致后续代码维护成本特别大，比如这次维修博客观看之前的提交历史，只能说我都不知道我修了个啥== 乱写 Commit 一时爽，后续维护火葬场。
其实也不能说是一时爽：很多时候也不能说是我们有意要瞎写提交消息的，有的时候这次 Commit 确实做的事情小到不拿放大镜看不到，为了这点东西想一段日后看起来不会一头问号的消息其实还挺尴尬的；这种时候就需要完善的规则来背书，才能避免这种前后都尴尬的情况。
规范
其实网上的规范还挺多，也有约定式提交这种看起来就很高大上的东西；但是实际上大多数人说到规范的第一反应还得是 Angular 规范；这里简单的讲讲
自用 Angular 规范
总的来说，一条消息应该由以下的部分组成
1 | <type>(<scope>): <subject> |
type（必须）
用于说明本次提交的类别，可以在以下关键字中选择：
| 类别 | 含义 | 说明 |
|---|---|---|
| feat/feature | 新的功能 | |
| fix | 修复 bug，已经解决了描述的问题 | |
| to | 修复 bug，问题还没解决 | 适用于多次提交；这个 bug 我修了好久了 |
| docs | 修改了文档 | |
| style | 调整了代码的格式，完全不影响代码的运行 | |
| refactor | 对已有代码的重构 | 一个更改，即没有增加新功能，也没有修复 bug，那它就是重构 |
| perf | 优化代码的表现，提升了性能/体验 | |
| test | 增加测试 | |
| chore | 构建过程/辅助工具的变动 | |
| revert | 版本回滚 | |
| merge | 代码合并 | |
| sync | 同步其他分支 |
其实还是挺抽象的…… 别的之后慢慢补充了……
scope（可选）
用于说明本次提交影响的范围；可以具体到功能模块，这就取决于不同的项目了。
subject（必须）
对本次提交进行简短的描述，往往不超过 50 个字符 —— 你超过了的话，VS Code 都会提醒你。
虽然说很多文章里都说要用英文，但是对于本就英文不熟悉的国人来说实在是有点要求过高…… 个人感觉如果只是自己的项目，自己写的三脚猫英语可能本身就是代码审阅时候的很大的障碍，所以要不还是不要折磨自己，乖乖说母语吧（）
description*（可选）
另起一行之后的 Commit Message 就不会出现在各大托管平台的提交历史页面了；而很多时候五十个字符也只能非常 High-level 的概括一下你做了什么—— 虽然说在正经的多人合作项目里不太可能出现这种事情，但是毕竟自己也会搞七搞八对嘛== 这种情况下就需要更加详细的说明。当然，我的的意思就是另起一行开始大段说明。
约定式提交
感觉区别不是很大，可以参见它们的网站。约定式提交 1.0
好处
除了方便代码审阅之外，还有一些角度可以理解这样的好：
- 倒逼每次改动都专注于一个事情，使得最终的代码修改历史更为清晰
当然，在一个人的项目里很多时候这种属于是给自己增加麻烦。 - 格式化的 Commit Message 可以用于自动化生成 CHANGELOG
确实，怎么会有人手写 ChangeLog 呢？
