关于git:Git提交信息要满足的格式

35次阅读

共计 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

如果提交信息的题目行前缀是 featfixperf,则该提交信息会呈现在更新日志中。其中,中断性变更永远都会呈现在更新日志中,不管题目行前缀是什么。

其它前缀用哪个,须要依据状况自行酌办。举荐应用的前缀 docs, chore, style, refactortest,这些前缀的提交信息不会呈现在更新日志中。

Scope

作用域能够是任何内容。

如文章结尾示例中的core,compiler, ssr, v-model, transition

Subject

概述是以后提交的简要形容

  • 应用复数、当初时,如“change”, 而不是 ”changed” 过来式,也不是 ”changes”。
  • 首字母不要大写
  • 不要以 "." 完结

Body

Subject 一样,应用复数、当初时,如“change”, 而不是 ”changed” 过来式,也不是 ”changes”。

主体内容应该包含更新的动机,以及这次提交与以前的提交的比照。

Footer

页脚正文应该蕴含对于中断性变更的任何信息,也是标注此提交敞开了哪条 GitHub 问题的中央。

中断性变更应该以单词 BREAKING CHANGES: 结尾,":"后追随一个空格或两个换行符。紧随 `BREAKING CHANGES: 后的其余提交音讯将用于标注解决了什么问题。

正文完
 0