Git 提交规范

git 规定提交时必须要写提交信息，作为改动说明，保存在 commit 历史中，方便回溯。规范的 log 不仅有助于他人 review, 还可以有效的输出 CHANGELOG，甚至对于项目的研发质量都有很大的提升。

规范

message 格式如下：

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

格式说明：

分别对应 Commit message 的三个部分：Header，Body 和 Footer

Header

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）

type: 用于说明 commit 的类型。一般有以下几种:

feat:        A new feature(新增feature)
fix:         A bug fix(修复bug)
docs:        Documentation only changes(仅文档更改,如README.md)
refactor:    A code change that neither fixes a bug nor adds a feature(代码重构，没有新增功能或修复bug)
perf:        A code change that improves performance(优化相关，如提升性能、用户体验等)
test:        Adding missing tests or correcting existing tests(测试用例，包括单元测试、集成测试)
build:       Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)(影响构建系统或外部依赖关系的更改（示例范围：gulp、broccoli、npm）)
chore:       Other changes that don't modify src or test files(其他不修改src或测试文件的更改)
improvement: An improvement to a current feature(对当前特性的改进)
style:       Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)(不影响代码含义的更改（空格、格式、缺少分号等）)
ci:          Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)(对ci配置文件和脚本的更改)
revert:      Reverts a previous commit(还原以前的提交)

scope: 用于说明 commit 影响的范围，比如: views, component, utils, config...
subject: commit 目的的简短描述

Body(已配置成必须)

对本次 commit 修改内容的具体描述, 可以分为多行
Footer

一些备注, 通常是 BREAKING CHANGE(当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。

格式参考

perf(compiler): use a shared interpolation regex (#34332)

The template parser has a certain interpolation config associated with
it and builds a regular expression each time it needs to extract the
interpolations from an input string. Since the interpolation config is
typically the default of `{{` and `}}`, the regular expression doesn't
have to be recreated each time. Therefore, this commit creates only a
single regular expression instance that is used for the default
configuration.

In a large compilation unit with big templates, computing the regular
expression took circa 275ms. This change reduces this to effectively
zero.

PR Close #34332

工程配置

手动执行git commit按照模板写入
借助第三方工具交互式写入 commit 信息

手动编写格式化模板

创建 commit 提交信息模板文件.gitmessage.txt

# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the issue.
# - BREAKING CHANGE
#

配置提交信息模板 git config commit.template .gitmessage.txt
执行git commit

借助第三方工具

commitizen交互式提交 commit 信息

依赖安装

# 安装commitizen
npm install --save-dev commitizen
# 安装适配器
npx commitizen init cz-conventional-changelog --save-dev --save-exact

配置

// package.json script字段中添加commit命令
"scripts": {
 "commit": "git-cz"
}
// 使用 npm run commit

commitlint提交验证工具

在 git commit 提交之前使用 git 钩子来验证信息。提交不符合规则的信息将会被阻止提交。

安装 npm install --save-dev @commitlint/cli @commitlint/config-conventional npm install --save-dev husky

配置

// package.json 中配置 commitlint 脚本
"commitlint": {
  "extends": [
    "@commitlint/config-conventional"
  ],
  "rules": {
    // 配置 body 为必须的
    "body-empty": [
      2,
      "never"
    ],
    // 配置 footer 为必须的
    "footer-empty": [
      2,
      "never"
    ]
  }
},
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

自定义 commitlint 规则

// 新建commitlint.config.js配置git提交规范
module.exports = {
  rules: {
    'body-leading-blank': [1, 'always'], // body开始于空白行
    'body-tense': [1, 'always', ['present-imperative']],
    'footer-leading-blank': [1, 'always'], // footer开始于空白行
    'footer-tense': [1, 'always', ['present-imperative']],
    'header-max-length': [2, 'always', 72], // 简述限制72字符长度
    'scope-case': [2, 'always', 'lowerCase'], // scope小写
    'subject-empty': [2, 'never'], // subject不为空
    'subject-full-stop': [2, 'never', '.'], // subject结尾不加'.'
    'subject-tense': [1, 'always', ['present-imperative']], // 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
    'type-case': [2, 'always', 'lowerCase'], // type小写
    'type-empty': [2, 'never'], // type不为空
    'type-enum': [
      2,
      'always',
      [
        'build', // 修改构建打包文件
        'chore', // 构建过程或辅助工具的变动
        'docs', // 文档（documentation）
        'feat', // 新功能（feature）
        'fix', // 修补bug
        'perf', // 性能优化
        'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）
        'revert', // 还原以前的提交
        'style', // 格式（不影响代码运行的变动）
        'test' // 增加测试
      ]
    ] // type关键字必须是其中之一
  }
}

使用示例

git commit
git commit -m
npm run commit

操作演示

手动模板

git commit git log
依赖第三方工具

npm run commit git log
结合commitlint

git commit -m | npm run commit

博文参考

利用`git hook`限制提交代码规范

防患于未然，防止将存在潜在问题的代码带到线上环境，最好的办法是在本地提交代码时就能够扫描出潜在的错误，并强制将其修改后才能提交，这样就不会将问题代码携带到线上，就能保证线上代码至少不会存在低级的程序错误

强制代码格式规范且统一
方便后续冲突解决

eslint+husky+prettier+lint-staged

foxpocker / commitlint

Git 提交规范

规范

格式说明：

格式参考

工程配置

手动编写格式化模板

借助第三方工具

使用示例

操作演示

博文参考

利用`git hook`限制提交代码规范

简介

发行版

贡献者

近期动态

foxpocker / commitlint .gitee-modal { width: 500px !important; }

Git 提交规范

规范

格式说明：

格式参考

工程配置

手动编写格式化模板

借助第三方工具

使用示例

操作演示

博文参考

利用git hook限制提交代码规范

简介

发行版

贡献者

近期动态

搜索帮助

foxpocker / commitlint

利用`git hook`限制提交代码规范