对于怎么写Git Commit 信息，每个人都有自己的看法，每个团队也有自己的规定。这并没有一个明确的标准，今天也不是来讨论标准，而是介绍一个相对优雅的方式。
[ac7536f1f] update some files
[cdc6708ad] change style
[93d4b716d] remove css files
[dfb928e85] update readme
之前，我写提交信息的时候，只会写主题信息。可能这样写的弊端大家也看到了，之后会看这些message的时候，并不知道这些提交到底是什么功能的。甚至有偷懒的同学可能会直接这么写 [52a9e19] Update ，能看懂这个commit message是update什么吗？可能在过段时间，这位同学也不知道是提交的什么了。
对于Git Commit Message并明确的标准，但也有一些好的原则：
- 使提交信息业务相关
- 提交信息中写明类型
- 必要时要写描述(Decription)
- 提交主题尽量简短
- 尽量使用英文
使提交信息业务相关
本文开头的第一个代码片段是我之前提交的提交记录，现在来看的话，我已经不知道我写了什么？如果要知道到底提交了什么，涉及哪些功能，也只有借助版本工具了。
提交信息和代码一样，不只是给自己看，也是给团队中其他人看的，同时也是对提交信息的注释。在我过往经历中，看到过很多小伙伴为了方便随便写提交信息。修复一个登陆问题，提交信息却只写了Fix bug。这就导致了对于代码的回溯和问题排查十分困难，时间久了甚至只能一个一个Commit的排查。要记住一点：提交信息不只是给自己看的，也是给团队看的。
示例
使用
实现单点登陆接口
替代实现新功能
有个小建议，大家可以在提交代码的时候，如果实在是想不到，可以直接使用需求描述作为提交信息。
提交信息中写明类型
先来对提交代码的原因进行分类，大致可以分为几类：新功能、代码升级或变更、Bug修复、文档编写、主题UI变更和测试用例。提交代码的原因不外乎就是这几种，所以现在给这些原因相应加上一个标识，就变成了如下列表。
- Feat: 新功能
- Upgrade：功能升级或代码变更
- Fix: Bug修复
- Doc: 文档或README编写
- Style: 主题UI变更
- Test：新增测试代码
示例
使用
Feat：实现单点登陆接口
替代实现单点登陆接口
提交信息尽量简短
想象一下，如果一条提交信息有几十个甚至近百个字，是不是很累。作为一个能偷懒就偷懒的程序猿，当然不可能写这么长的提交信息的。只要在能够正确表达出本次提交所代表含义的情况下，字数尽量少，最好不超过50个字符。
示例
使用
Feat：实现单点登陆接口
替代实现单点登陆接口，并修改了Login.java...（此处省略100字）
篇幅原因，错误示例就用省略号(…)来代替。可以看到绿色示例已经正确能够表达本次提交的主题了，所以完全没有必要写这么多字。
必要时要写描述(Decription)
描述是对提交信息的补充说明或详细描述，这部分内容很少有同学会注意到。但有时候描述却也不可缺少，比如说当合并代码存在冲突的时候，提交者就有必要将发生冲突的文件写在描述信息里面。
描述信息可以分为多行，可以在第72个字符的地方进行换行。
示例
使用
Upgrade: Update meta
- update contributors
- update eslint
- update jest
- update webpack
Upgrade: Update meta
尽量使用英文
有人会说中文本就是母语，为什么不建议使用中文。在团队开发中，使用中文能够表达的更清楚明白。且一个团队里面，并不是所有的人英文都很好，如果要使用英文则需要保证你写的提交信息其他人也能看懂，否则就会适得其反了。
大家或多或少都使用过Windows来进行开发，当使用过 cmd来查看git log的时候，中文是乱码的。这实在是太不友好，如果要正常显示还要一顿骚操作。这也就是为什么建议尽量使用英文了。
其实还有一个原因，如果我们写一个开源项目的话，提交到GitHub上面就是面向全世界的开发者，那么提交信息使用英文就十分友好了（说不定项目就火了呢）。
英文信息格式
如果要使用英文，那么就得注意一下提交的文本格式。英文的大小写和符号有无都会影响提交信息的美观。那我们就要对英文格式做一些约束。
- 语句的首字母使用大写字符
- 语句结尾不要有句号(.)
示例
使用
Fix: Fix can't login bug
替代Fix：修复不能登录的bug
文章持续更新，扫描下方二维码关注公众号第一时间阅读
本文首发于： https://baozi.fun/2020/07/10/write-elegant-commit-message
本文使用 mdnice 排版
