共计 1470 个字符，预计需要花费 4 分钟才能阅读完成。
Git提交信息的格局要满足如下 /^(revert:)?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip|dep)(\(.+\))?: .{1,50}/ 正则表达式
示例
-
如下提交信息呈现在
Features大题目，compiler次题目下：feat(compiler): add 'comments' option展现如下：
Features compiler: add 'comments' option -
如下提交信息呈现在
Bug Fixes大题目，v-model次题目下，跟随着#28问题的链接：fix(v-model): handle events on blur close #28 -
如下提交信息呈现在
Performance Improvements大题目，core次题目下，BREAKING CHANGE下一行跟随着中断性变更的理由：perf(core): improve vdom diffing by removing 'foo' option BREAKING CHANGE: The 'foo' option has been removed. -
如果以下提交和提交 667ecc1 在同一版本下，则该提交信息不会呈现在变更日志中。如果没有在同一版本下，该提交将呈现在“Reverts”大题目下
revert: feat(compiler): add 'comments' option This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
残缺提交信息的格局
提交信息蕴含题目行、主体内容和页脚正文，其中，题目行蕴含批改类型type、批改影响的范畴（作用域）scope、批改内容概述subject。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>以上，首行是题目行，题目行是必填的，题目行的作用域 scope 是可选的。
Revert
如果某个提交回滚到上一次提交，提交信息应该以 revert: 开始，后续是该提交的题目行。
主体内容应该写 "This reverts commit <hash>"，其中，<hash> 指向要回滚的提交。
Type
如果提交信息的题目行前缀是 feat、fix 或perf，则该提交信息会呈现在更新日志中。其中，中断性变更永远都会呈现在更新日志中，不管题目行前缀是什么。
其它前缀用哪个，须要依据状况自行酌办。举荐应用的前缀 docs, chore, style, refactor 和test，这些前缀的提交信息不会呈现在更新日志中。
Scope
作用域能够是任何内容。
如文章结尾示例中的core,compiler, ssr, v-model, transition…
Subject
概述是以后提交的简要形容
- 应用复数、当初时，如“change”, 而不是 ”changed” 过来式，也不是 ”changes”。
- 首字母不要大写
- 不要以
"."完结
Body
和 Subject 一样，应用复数、当初时，如“change”, 而不是 ”changed” 过来式，也不是 ”changes”。
主体内容应该包含更新的动机，以及这次提交与以前的提交的比照。
Footer
页脚正文应该蕴含对于中断性变更的任何信息，也是标注此提交敞开了哪条 GitHub 问题的中央。
中断性变更应该以单词 BREAKING CHANGES: 结尾，":"后追随一个空格或两个换行符。紧随 `BREAKING CHANGES: 后的其余提交音讯将用于标注解决了什么问题。
