规范参考
约定式提交 https://www.conventionalcommits.org/zh-hans/
<类型>: 改了什么内容
^----^ ^---------^
| |
| +-> 简明扼要的说明本次提交的意图.
|
+-------> 类型范围: chore, docs, feat, fix, refactor, style, or test.
类型说明
| 类型 | 说明 |
|---|---|
| feat | 用户功能的新特性（项目自身构建方式的更新，不算新特性） |
| fix | 用户功能修复（项目自己的构建错误修复，不算功能修复） |
| docs | 更新文档 |
| style | 代码格式化或风格变化 |
| refactor | 重构（修改变量名、文件目录结构等不影响功能的变动） |
| test | 增加、修改测试代码，不涉及生产运行代码变化 |
| chore | 日常维护，不涉及生产运行代码变化（写错个字、变更个版本号啥的） |
如果已提交记录不符合规范，可以使用 git 重写提交记录 的方法进行修改。
优秀案例
看看 git 的发明者：linus 是怎么写提交信息的
简单内容参考
复杂内容参考
有从 Linux+Git 之父身上学到吗？
真实情况
作为一名老程序员，需要讲述真实。以上，都是学术思想的理论规范。实际在写 commit 信息的时候，是很难达到的。因为优秀的提交规范基于这样一个核心假设：
你的 commit 是有意义的。
同时为了补充例外情况，提交规范还默认你有这样的能力：
你可以修改历史提交记录。
然而，项目中这两条都是不允许的。真实的项目以业务为主，大量的冗余、反复、的细节需求更改，导致你的提交中有很多是无意义的。我们常听到这句：还是用刚才那个版本吧。这时候一个 commit 加一个 revert 就是两个提交了。
我们难道不能做好了再提交上去吗？
不能。原因有两个，一个是环境，你做好之后必须通过提交，才能发布到可以测试的环境；另一个是，功能往往是两个人合作（前端+后端模式），两个人要同步代码，此时至少需要一个人提交。
我们难道不能时候通过重写 git 提交记录来优化提交信息吗？
不能。变更 git 历史记录意味着分叉，一旦出大型分叉（100个commit差异，500个文件变化）你怎么跟主干分支合并？merge 或者 rebase？出现冲突的话你能 resolve 吗？很可能冲突的编程语言你都没写过。直接覆盖 master 吗？代码冲突倒是没了，但是你小心接下来会有肢体冲突！
大家都怎么写 commit 信息
真是情况是这样的：
- 跟绩效挂钩：认真写，可能提交信息写的比代码变更还多。
- git commit 钩子，比如 husky：符合规范的格式（不然不能commit），但内容没有太大意义，反正提交上去就好。
- 给大家指导规范，然后自己注意：各种牛鬼蛇神的提交就都上来了，少数符合提交规范的提交，此时也显得没啥用处。
为什么大家都不认真写 commit 信息？
请你自己想一下，你什么时候翻过一年前的提交的 commit 信息？毕竟，你做的又不是开源项目，毕竟看变动记录应该直接翻代码版本，看提交信息作甚？说到底，大部分项目质量不高，在无人观察的角落，谁还会在意自己的举止是否得体。
该怎么写 commit 信息
好习惯是慢慢养成的，从现在开始认真按照规范来写。 -- 高质量项目
