():
大致分为三个部分(使用空行分割):
1. 标题行: 必填, 描述主要修改类型和内容
2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
3. 页脚注释: 放 Breaking Changes 或 Closed Issues
commit 的类型:
commit 影响的范围, 比如: route, component, utils, build,一般填写当前修改目 录或者功能模块的名称,例如修改公共包公共包,影响范围就是全局。
commit 的概述
commit 具体修改内容, 可以分为多行.
一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
• 每个提交都必须使用类型字段前缀,它由一个名词组成,诸如 feat 或 fix ,其后接一个可选的作用域字段,以及一个必要的冒号 (英文半角)和空格。
• 当一个提交为应用或类库实现了新特性时,必须使用 feat 类型。
• 当一个提交为应用修复了 bug 时,必须使用 fix 类型。
• 作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代 码的名词,并用圆括号或者中括号包围,例如: fix(parser):/ fix[parser]:
• 描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结,例如: fix: array parsing issue when multiple spaces were contained in string.
• 在简短描述之后,可以编写更长的提交正文,为代码变更提供额外的上 下文信息。正文必须起始于描述字段结束的一个空行后。
• 在正文结束的一个空行之后,可以编写一行或多行脚注。脚注必须包含 关于提交的元信息,例如:关联的合并请求、 Reviewer 、破坏性变更,每条元信息一行。
• 破坏性变更必须标示在正文区域最开始处,或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE,后面紧跟冒 号和空格。
• 在 BREAKING CHANGE: 之后必须提供描述,以描述对 API 的变更。例如: BREAKING CHANGE: environment variables now take precedence over config files.
• 在提交说明中,可以使用 feat 和 fix 之外的类型。
• 工具的实现必须不区分大小写地解析构成约定式提交的信息单元,只 有 BREAKING CHANGE 必须是大写的。
• 可以在类型/作用域前缀之后, : 之前,附加 ! 字符,以进一步提醒注意破坏性变更。当有 ! 前缀时,正文或脚注内必须包含 BREAKING CHANGE: description
如果修复的这个 BUG 只影响当前修改的文件,可不加范围。如果影响的范围比 较大,要加上范围描述。
例如这次 BUG 修复影响到全局,可以加个 global。如果影响的是某个目录或
某个功能,可以加上该目录的路径, 或者对应的功能名称。建议使用中文
// 示例 1
Fix[lobal]:修复 checkbox 不能复选的问题
// 示例 2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的 BUG,将通用管理下所有页面的默认字体大小修改为 14px
// 示例 3
fix: value.length -> values.length
feat【登录模块】 : 添加网站主页静态页面
这是一个示例, 假设对点检任务静态页面进行了一些描述。
这里是备注,可以是放 BUG 链接或者一些重要性的东西。
chore 的中文翻译为日常事务、例行工作,顾名思义,即不在其他 commit 类 型中的修改,都可以用 chore 表示。
chore: 将表格中的查看详情改为详情