总结比较优雅的Git commit提交日志格式
介绍
<Header> # 必需的
<Body> # 可选
<Footer> # 可选
feaute: func ..
More abcdefs ... sdf fatures
very good
- feature 1
- feature 1
close #1661
<type>: <subject>
每次代码提交必须有备注说明，注明本次提交做了哪些修改，commit type类别：
- feature/feat：新功能（feature）
- bugfix/fix：修补bug
- docs/doc：文档（documentation）
- style：格式（不影响代码运行的变动）
- sprintfix: 未上线代码修改 （功能模块未上线部分bug）
- refactor：功能重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
- minor: 不重要的修改（换行，拼写错误等）
- optimization：功能优化
subject是 commit 目的的简短描述。以动词开头，使用第一人称现在时，比如改变，而不是改变了。结尾不加句号（。）
Body 格式
Body 部分是对本次 commit 的详细描述，可以分成多行。
Footer 部分应该包含：
- 关闭issue，格式为：
... #<issue id>
review 相关缩写
Github 上的码农们在 code review 信息：
PR: Pull Request 拉取请求，给其他项目提交代码LGTM: Looks Good To Me 朕知道了代码已经过 review，可以合并SGTM: Sounds Good To Me. 和上面那句意思差不多，也是已经通过了 review 的意思WIP: Work In Progress. 传说中提 PR 的最佳实践是，如果你有个改动很大的 PR，可以在写了一部分的情况下先提交，但是在标题里写上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码。PTAL: Please Take A Look. 用来提示别人来看一下TBR: To Be Reviewed. 提示维护者进行 reviewTL;DR: Too Long; Didn't Read. 太长懒得看。也有很多文档在做简略描述之前会写这么一句TBD: To Be Done(or Defined/Discussed/Decided/Determined). 根据语境不同意义有所区别，但一般都是还没搞定的意思