编码中少部分人写commit message仅仅是为了要提交代码，也有一些同学清楚commit message是为了记录提交的内容是什么，但是业务中还是有很多不知道是做了什么的commit message.
比如：
看到这个message，根本不知道是什么体验问题，即使代码编写人本人，过一段也会不记得，必须通过读代码才知道修改了什么体验问题
再看一个commit message
这个message显然就很清晰，不看代码也知道做什么，message指明了哪个页面，实现了什么功能调整
我们要首先明确写commit message的作用
- 每一条提交记录的message能够提供更多的有效信息，方便我们快速浏览
- 可以使用git log --grep <keyword>过滤掉某些commit，便于快速查找信息
- 可以直接从commit生成Change log
实际业务场景中好的message可以帮助我们
快速找到某一次功能调整，方便不用读代码就能确认一些变更或者再次对相关功能做调整
帮助理解代码，通过message知道修改的代码的功能，Review代码可以更高效
那么我们要如何写好commit message
首先格式建议
代码语言：javascript复制<type>(<scope>): <subject>
< 空一行 >
<body>
< 空一行 >
<footer>body和footer可以不写
type用于说明commit的类别，具体如下
- feat： 一个新的功能（feature）；
- fix：修复bug;
- docs：修改文档，比如README.md、CHANGELOG.md等；
- style: 修改代码的格式，不影响代码运行的变动，比如空格、格式化代码、补齐句末分号等等；
- refactor: 代码的重构，没有新功能的添加以及bug修复的代码改动；
- perf：优化代码以提高性能；
- test：增加测试或优化改善现有的测试；
- build：修改影响项目构建文件或外部依赖项，比如npm、gulp、webpack、broccoli等；
- ci：修改CI配置文件和脚本；
- chore：其他非src路径文件和测试文件的修改，比如.gitignore、.editorconfig等；
- revert：代码回退；
subject为修改内容的简要描述
我自己通常只用subject把修改内容描述清楚，不再使用body和footer
在开发中尽量一件事一个commit，也就是一个commit message描述一件事，（实践中也存在多个小功能一起commit的情况，我通常用分号分割不同功能。多个小功能一个commit的缺点是无法把其中一个功能cherry pick到别的分支）。要保证commit的功能逻辑是完整的，其他同事拉下代码业务可以正确运行。
写commit时，脑袋中的思考，是看message的人完全不知道上下文，不能预设别人知道什么，可以简写。也不可以预设看一下代码文件就知道是哪一块的功能
前端的很多业务，可以从页面分类、页面再到具体修改了什么功能的描述方式描述
还有两种场景，可以单独提一个commit来描述
1. 逻辑调整很复杂，专门一个commit提交，把复杂的逻辑描述清楚，方便后续Review时理解
2. 特殊的业务设定，单独提一个commit，后续读到这一块代码不理解，看下commit message就明白了
那么这些情况为什么不用代码注释，在《代码整洁之道》这本书详细解释了，注释不会有人维护，代码改了、删了，注释还会在。而commit message，是在看到还存在的代码时，去查看message。
对于前端同学，写message时，可以思考为在什么地方实现了什么功能。
如果你是一个精简写message的Coder，可以先改变为把修改描述清楚。如果你写message已经很清晰，可以考虑精简凝练描述，简明扼要写清楚实现的功能。
再也不要出现无意义的message...
