Front-end submission information specification-commitlint

One installation

You need to ensure that you have installed Husky

npm install --save-dev husky

安装@commitlint/config-conventional @commitlint/cli

npm install --save-dev @commitlint/config-conventional @commitlint/cli

Second placement

Generate the configuration file commitlint.config.js, of course it can also be .commitlintrc.js

echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

Add CommitlIint configuration in husky configuration, v1.0.1after version is HUSKY_GIT_PARAMS, v0.14.3forGIT_PARAMS

"husky": {
    "hooks": {
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },

Three submission specifications

3.1 Submission format (note the space after the colon)

git commit -m <type>[optional scope]: <description>

3.1.1 Common type categories

type: Used to indicate the type of change we submitted this time, is it a new feature? Or did you modify the test code? Or has the document been updated? Summarize the following 11 types:

  • build: The main purpose is to modify the submission of the project build system (such as the configuration of glup, webpack, rollup, etc.)
  • ci: The main purpose is to modify the project to continue the integration process (such as Travis, Jenkins, GitLab CI, Circle, etc.) submission
  • docs: Documentation update
  • feat: new feature
  • fix: bug fix
  • perf: performance optimization
  • refactor: refactored code (no new features or bug fixes)
  • style: Code modification that does not affect the program logic (modify blank characters, complete missing semicolons, etc.)
  • test: add test cases or update existing tests
  • revert: roll back an earlier commit
  • chore: other types that do not belong to the above types (daily affairs)

optional scope: An optional modification scope. It is used to identify which module in the code this submission mainly involves.

description: Describe the main content of this submission in one sentence, so as to be concise.

example:

git commit -m 'feat: 增加 xxx 功能'
git commit -m 'bug: 修复 xxx 功能'

3.1.2 subject

subject is a short description of the purpose of the commit, and some configuration can be done, such as the maximum length limit.

3.2 commitlint.config.js file configuration

Rule configuration description: rule consists of name and configuration array, such as: 'name: [0,' always ', 72]', the first digit in the array is level, optional 0,1,2, 0 is disable, 1 It is warning, 2 is error, the second is application or not, optional always | never, the third is the value of the rule. Specific configuration examples are as follows:

module.exports = {
  extends: [
    "@commitlint/config-conventional"
  ],
  rules: {
    'type-enum': [2, 'always', [
      'upd', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert'
     ]],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72]
  }
};

Here is a list of most commonly used configurations, others can refer to the Commitlint website

Guess you like

Origin www.cnblogs.com/qiqi715/p/12737297.html