共计 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: 后的其余提交音讯将用于标注解决了什么问题。