约定式提交

                     

贡献者: int256

   约定式提交规范是一种在进行代码变更时的轻量级约定。约定式提交制定了一组简单的规则来创建清晰的提交历史,便于编写自动化工具。通过在提交信息中描述功能、修复和破坏性变更(Breaking Change)(下文会对破坏性变更做出解释),使这种惯例与语义化版本相互对应。

1. 简介

   对于每次提交的代码变更,说明结构:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
可以对应翻译为,
<类型>[(可选)范围]: <描述>

[(可选)正文]

[(可选)脚注]
提交说明描述了下列内容,可以向使用者与协同编辑者说明本次变更的内容:

  1. fix:这代表本次提交修复了一些 bug(对于修复多个 bug,建议多次提交)。这对应语义化版本的 PATCH
  2. feat:这代表本次提交实现了新的功能(对于实现多个功能,也建议多次提交)。这对应语义化版本的 MINOR
  3. BREAKING CHANGE:一般在类型后面加感叹号表示本次提交是一个破坏性变更,表示引入了破坏性 API 变更,破坏性变更可以是任意类型的提交的一部分。这对应语义化版本的 MAJOR。可以将破坏性变更理解为,进行了某些重大更新,使旧版本不再兼容(有时重大更新,对用户使用有严重影响的,也可以使用破坏性变更表示)。破坏性变更应在脚注中标注内容

   除了 fix(!)feat(!) 以外,类型也可以是 @commitlint/config-conventional 中推荐的任意一个,下面给出一些另外常用的类型:

  1. build: 用于修改项目构建系统,例如修改依赖库、外部接口或者升级 Node 版本等;
  2. chore: 用于对非业务性代码进行修改,例如修改构建流程或者工具配置等;
  3. ci: 用于修改持续集成流程,例如修改 Travis、Jenkins 等工作流配置;
  4. docs: 用于修改文档,例如修改 README 文件、API 文档等;
  5. style: 用于修改代码的样式,例如调整缩进、空格、空行等;
  6. refactor: 用于重构代码,例如修改代码结构、变量名、函数名等但不修改功能逻辑;
  7. perf: 用于优化性能,例如提升代码的性能、减少内存占用等;
  8. test: 用于修改测试用例,例如添加、删除、修改代码的测试用例等。

   其它提交类型在约定式提交规范中并没有强制限制,并且在语义化版本中没有隐式影响(除非它们包含破坏性变更)。可以为提交类型添加一个围在圆括号内的范围,以为其提供额外的上下文信息。例如 feat(console): adds ability to active console in game.。当然,描述也可以是中文的,但是描述是必要的,且破坏性变更的脚注也是必要的

   如果一次变更符合多种类型,应当予以拆分,并多次提交。

2. FAQ

   1. 类型打错了怎么办?写错了怎么办? 例如本身是 feat,不小心打成了 faat 或者 fix

   在发布或合并之前,可以采用 git 提供的 git rebase -i 来修改历史功能。

   2. 在约定式提交规范下,还原怎么办? 特别规定还原为 revert 类型,并且建议在正文中进行描述。下面有一个例子:

revert: the cake is a lie.

Refs: 1298560a, c9012783

   3. 变更范围涉及多个怎么办? 如果是全局,可以使用 *all(推荐)来表示;如果是主体、主逻辑,可以使用 main 来表示。 如果修改了多个文件导致范围涉及广,建议拆分为多次提交。对于单次修改的,可以在描述中指出变更范围而在括弧内写 *

                     

© 小时科技 保留一切权利