preface

A non-committee-specific commit may not even be remembered a month later for the purpose of committing the code, but a regular commit can help locate problems better, so it’s important that teams follow the same set of Commit message specifications in order to make it easier to recover and find bugs later.

This article focuses on the most widely used COMMIT specification, which is reasonable and systematic, and has a companion Lint tool.

A commit message function

  • Provides more historical information for quick browsing.
  • Certain commits, such as document changes, can be filtered to make it easy to find information quickly.
  • You can generate Change logs directly from commit.

Commit Message format description

A commit message consists of three parts: Header, Body, and Footer

<type>(<scope>): <subject>
/ / an empty line
<body>
/ / an empty line
<footer>
Copy the code

Header is mandatory, Body and Footer are optional.

Header

Header contains three fields: type (required), scope (optional), and subject (required) ‘.

type

Type indicates the type of commit. Here are the eight common identifiers:

  • Feat: A new feature
  • Fix: Fixed a Bug
  • Docs: Updated document (e.g. Readme)
  • Style: Style modification of code that does not involve feature changes (such as indentation)
  • Refactor: Structural improvements to code that are neither new features nor Bug fixes (e.g., changing the name of a function)
  • Perf: Code changes that optimize performance
  • Test: Adds or modifies the existing test code
  • Chore: functional changes to build/engineering dependencies/tools that are not related to the warehouse’s primary business (such as adding a document generation tool)

If type is feat and fix, the commit will definitely appear in the Change log.

scope

Scope is used to specify the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project.

subject

Subject is a short description of the commit purpose, no more than 54 characters long

Start with a verb and use the first person present tense, such as "change", not "changed" or "changes".Copy the code

body

The Body section is a detailed description of the commit, broken into multiple lines. The git-cz command does not allow line breaks.

Footer

The Footer section is only used in two cases

  • Incompatible variation

If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method.

  • Shut downIssueIf the currentcommitFor aissue, then can be inFooterPartially close thisissue
Closes #123, #245, #992
Copy the code

Installation and use

The commit specification and lint checking tool will be added to the project starting from 0

Install git – cz

Global installation

After installation, directly replace git COMMIT with git Cz

npm install -g git-cz
Copy the code

Local installation

Install Git-cz and Commitizen

Install commitizen to initialize the commit specification
npm install -g commitizen
npm install --save-dev git-cz
# Use THE CZ-Conventional - Changelog specification (default defined rules)
commitizen init cz-conventional-changelog --save-dev --save-exact
Copy the code

The following content is automatically added to package.json after the above installation is complete

{
  "devDependencies": {
  	// ...
    "cz-conventional-changelog": "^ 3.2.0",},"config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"}}}Copy the code

Run NPX git-cz or add NPM scripts and run NPM commit

"scripts": {
    "commit": "git-cz"
},
Copy the code

After this command is executed, you can select commit

The next step is to fill in the contents of body and subsequent footer, which can be skipped. However, if the contents submitted at one time are too many, it is recommended to fill in the detailed description of body. Footer is rarely used in general. Fill in the corresponding value. The body has been tried many times, but the command line can not be newline, if you find the way of newline, welcome to correct, thank you! You can also use git tools to fill in the commit message

Added changelog.config.js for custom configuration

// Changelog is configured. Commit rules are also configured here
/ / reference document: https://www.npmjs.com/package/git-cz

module.exports = {
  "disableEmoji": false."list": [
    "test"."feat"."fix"."chore"."docs"."refactor"."style"."ci"."perf"]."maxMessageLength": 64."minMessageLength": 3."questions": [
    "type"."scope"."subject"."body"."breaking"."issues"."lerna"]."scopes": [].// Translate the description
  "types": {
    "chore": {
      "description": "Build/engineering dependencies/tools and other functional changes unrelated to the main business of the warehouse (such as adding a document generation tool)"."emoji": "🤖"."value": "chore"
    },
    "ci": {
      "description": "CI related changes"."emoji": "🎡"."value": "ci"
    },
    "docs": {
      "description": "Updated document (such as Readme)"."emoji": "✏ ️"."value": "docs"
    },
    "feat": {
      "description": "A new feature"."emoji": "🎸"."value": "feat"
    },
    "fix": {
      "description": Fix the bug"."emoji": "🐛"."value": "fix"
    },
    "perf": {
      "description": "Code changes that optimize performance"."emoji": "⚡ ️"."value": "perf"
    },
    "refactor": {
      "description": "Some code structure improvements, neither new features nor Bug fixes (such as changing function names)"."emoji": "💡"."value": "refactor"
    },
    "release": {
      "description": "Create a release commit"."emoji": "🏹"."value": "release"
    },
    "style": {
      "description": "Styling of code that does not involve functional modifications (such as indentation)"."emoji": "💄"."value": "style"
    },
    "test": {
      "description": "Add or modify existing test code"."emoji": "💍"."value": "test"}}};Copy the code

Commit Message Lint validation

When there are too many people, it is inevitable that there will be a problem of non-standard COMMIT messages. Even for projects that are not developed by multiple people, it is necessary to standardize commit messages.

Installing lint

# commit Lint tool
npm i @commitlint/cli -D
# commit Lint common configuration
npm i @commitlint/config-conventional -D
Install husky to trigger the validation rule at commit message
npm i husky
Copy the code

Configuration husky

"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}Copy the code

Add the configuration file. Commitlintrc.js

module.exports = {
  // commit Lint verifies rule inheritance
  extends: ['@commitlint/config-conventional'].// Customize the verification rule
	rules: {}};Copy the code

After the configuration is complete, each commit is verified. If the verification fails, the COMMIT is intercepted

Generate the CHANGELOG. Md

Use standard-version to generate Changelog.md

Installation and use:

npm i -S standard-version
Copy the code

Package. Json configuration:

"scirpt": {... ."release": "standard-version"
}
Copy the code

NPM run release generates Changelog.md

Standard-version has many features. Check out the official documentation: Standard-version

The last

Many are directly copied, and then their own continuous verification, from contact to use of the whole process recorded down

References:

Normalize your COMMIT message and automatically generate Changelog.md based on the COMMIT

Gracefully Commit your Git Commit Message

Commitizen + Husky specification git commit information

Many places are directly to NPM search related packages to view the document, welcome to point out any problems, useful welcome a thumbs-up