1. commit message 规范 <type>(<scope>): <subject>// 空一行// 空一行// 示例docs(guide): updated fixed docs from Google DocsCouple of typos fixed:- indentation- batchLogbatchLog -> batchLog- start periodic checking- missing brace type： 说明 commit 类型scope：可选，用于说明 commit 影响的...
type为必填项,用于指定commit的类型,约定了feat、fix两个主要type,以及docs、style、refactor、test、chore、五个特殊type,其余type扩充build、perf、ci、revert,也可以根据公司特殊要求做对应的扩展。 Header 里 type 部分 主要: init: 代码初始化 feat:新功能(feature) fix:修复bug 特殊: refactor:重构(代码重构时...
2.2 commit message 规范格式 [<type>:<systemScope>][<project>#<taskId/bugId/issueId>] : <subject> 2.2.1 type(必须) type(必须) : 用于说明git commit的类别,只允许使用下面的标识。 init : 初始化相关(工程、系统) feat : 新功能(feature) ...
chore: 不修改src或者test的其余修改,例如构建过程或辅助工具的变动 当一次改动包括主要type与特殊type时,统一采用主要type。 2. scope scope也为必填项,用于描述改动的范围,格式为项目名/模块名,例如: node-pc/common rrd-h5/activity,而we-sdk不需指定模块名。如果一次commit修改多个模块,建议拆分成多次commit,以...
我们每次提交,commit message 都包括三个部分:Header,Body 和 Footer。 // 空一行 // 空一行 其中,Header 是必需的,Body 和 Footer 可以省略。 Header格式如下: <type>(<scope>): <subject> 不管哪个部分,任何一行字符不要太多。这是为了避免自动换行影响美观。 1.Header header部分只有一行,包括三个...
commit message的提交很多时候都只依赖开发人员的自我规范,而开发人员往往在需求紧急或者bug要及时修复的时候,根本不会花很多时间在写git commit message的信息。而且就算是写,每个人的风格也不一样,所以写出来的message也不完全相同。 这个时候我们就需要有一套规范了,现在业界比较常用的规范是的格式是这样的:type(sco...
message 格式 <type>(<scope>):<subject><!-- 空行 --><!-- 空行 --> 2.1 *<type>提交类别 必填,<type>在commit的message中是必须存在的。<type>可以有以下取值 2.2<scope>影响范围 非必填(建议填写),<scope>用于说明commit影响的范围,建议填写影响的功能模块。 如果修改影响不止...
commit message格式 <type>(<scope>):<subject> type(必须) 用于说明git commit的类别,只允许使用下面的标识。 feat:新功能(feature)。 fix/to:修复bug,可以是QA发现的BUG,也可以是研发自己发现的BUG。 fix:产生diff并自动修复此问题。适合于一次提交直接修复问题 ...
$ git commit Commit Message 格式 Commit Message 包括三个部分:Header,Body 和 Footer。 <Header> <Body> <Footer> 其中,Header 是必需的,Body 和 Footer 可以省略。 Header Header 部分只有一行,包括三个字段:type(必需)、scope(可选)、subject(必需)。
$ git commit 1. Commit Message 格式 Commit Message 包括三个部分:Header,Body 和 Footer。 <Header> <Body> <Footer> 1. 2. 3. 4. 5. 其中,Header 是必需的,Body 和 Footer 可以省略。 Header Header 部分只有一行,包括三个字段:type(必需)、scope(可选)、subject(必需)。