Git解决方案之提交规范

Flyfreelylss

已于 2023-08-17 10:37:59 修改

阅读量5.3k

点赞数 9

分类专栏： git 文章标签： git github

于 2022-07-15 13:19:13 首次发布

原文链接：https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/;https://zhuanlan.zhihu.com/p/90281637

版权

git 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

以面试题为目标来进行学习，不定期推出前端高频面试题及其解析，题无简难，重在积累，欢迎wx关注西西星球！

1 概述

格式：

<type>(<scope>): <subject>

<body>

<footer>

上述大概分为3部分（使用空行分割）：

标题行（必填）：描述主要修改类型和内容
主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
页脚注释: 放 Breaking Changes 或 Closed Issues

标题行

type(必填): 用于说明commit的类别，只允许使用以下几个标识：

feat：新功能（feature）
fix：修改bug
docs：文档修改
style：代码格式修改（不影响代码运行的变动，例如分号修改），注意⚠️不是 CSS 修改
refactor：代码重构
test：测试用例修改
build: 影响项目构建或依赖项修改，如 webpack版本升级等
perf: 性能优化
revert: 撤销之前的 commit
ci: 持续集成相关文件修改
chore：其它修改（不在上述类型中的修改）

scope(可选): 用于说明commit的影响范围，比如route、component、utils、build等，视项目不同而不同。

subject(必填): commit信息的简短描述，不超过50个字符，要求如下：

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

主题内容

body: commit 具体修改内容, 可以分为多行。

页脚注释

footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接。

2 示例

2.1 feat

# 包含了描述以及正文内有破坏性变更的提交说明
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

# 包含作用域的提交说明
feat(lang): add polish language

2.2 fix

# 为 fix 编写的提交说明，包含（可选的） issue 编号
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

2.3 chore

# 包含了可选的 ! 字符以提醒注意破坏性变更的提交说明
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April

2.4 docs

# 不包含正文的提交说明
docs: correct spelling of CHANGELOG

3 约定式提交规范

每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
当一个提交为应用修复了 bug 时，必须使用 fix 类型。
作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： 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