约定式提交

                     

贡献者: 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 来表示。 如果修改了多个文件导致范围涉及广,建议拆分为多次提交。对于单次修改的,可以在描述中指出变更范围而在括弧内写 *


致读者: 小时百科一直以来坚持所有内容免费无广告,这导致我们处于严重的亏损状态。 长此以往很可能会最终导致我们不得不选择大量广告以及内容付费等。 因此,我们请求广大读者热心打赏 ,使网站得以健康发展。 如果看到这条信息的每位读者能慷慨打赏 20 元,我们一周就能脱离亏损, 并在接下来的一年里向所有读者继续免费提供优质内容。 但遗憾的是只有不到 1% 的读者愿意捐款, 他们的付出帮助了 99% 的读者免费获取知识, 我们在此表示感谢。

                     

友情链接: 超理论坛 | ©小时科技 保留一切权利