Implement a custom git submission specification

Implement a custom git submission specification

Submit a standardized environment to build

Why standardize Git submission

A good submission record will clearly display the scope, content, and bugs involved in each submission, and the format is consistent, which makes it easy to find the submission record and is more friendly to people who view the code submission record or review. Able to better understand the life cycle of the project and the problems that arise in the middle.

The standard Git submission will use the following dependent plugins. Below are the plugins I used and the corresponding version numbers

  • "commitizen": "^4.2.3"
    ,//Commitizen is a tool to help write standardized commit messages
  • "cz-conventional-changelog": "^3.3.0"
    ,//Adapter, used to provide the agreed submission format, different adapters can be used for different requirements
  • "@commitlint/config-conventional": "^12.1.1"
    ,//Community-defined submission specifications
  • "@commitlint/cli": "^12.1.1"
    Command,//verify submitted information line tool documentation
  • "commitlint-config-cz": "^0.13.2"
    ,//Used to customize the submission format
  • "cz-customizable": "^6.3.0"
    ,//Customized submission specification prompt copy
  • "husky": "^6.0.0"
    ,//husky is a Git Hook tool. Husky is a tool for adding hooks to git clients

Two methods will be introduced below:

  • Global installation, using a third-party submission format provided by conventions
  • The project depends on installation, and the submission method agreed by the custom specification is used

The first type: global installation

  • Installation dependencies

npm i -g commitizen cz-conventional- changelog duplicated code
  • generate
    .czrc
    file

    run

    echo'{"path":"cz-conventional-changelog"}'> ~/.czrc
    Generate a .czrc file under the root path, and specify the Adapter for commitizen.

    Note: If it is installed globally

    • mac OS
      Can be executed directly
      echo'{"path":"cz-conventional-changelog"}'> ~/.czrc
      Will be generated under the path
      .czrc
      file
    • window
      If you execute directly
      echo'{"path":"cz-conventional-changelog"}'> ~/.czrc
      This command will report an error because
      ~/
      Yes
      Linux
      The command represents the root path, as for how to
      window
      Generated under the root path
      .czrc
      I don t know the command of this file, and I don t know where
      window
      The next follow path refers to that path
  • Configuration
    package.json

"scripts" :{ commit : "git-cz" }, "config" :{ "commitizen" :{ "path" : "node_modules/cz-conventional-changelog" } } Copy code

After completing the above configuration, you can use it

git cz
Command, you can also use the configuration
packge.json
Run later
npm run commit
Make a submission

The second type: project dependent installation

  • Installation dependencies

npm i -D commitizen cz-conventional- changelog duplicated code

run

echo'{"path":"cz-conventional-changelog"}'> .czrc
Generate a .czrc file in the current path, and specify the Adapter for commitizen.

Note: need to remove the single quotes in the .czrc file

Correct

package.json
File add the following configuration

"scripts" :{ commit : "git-cz" }, "config" :{ "commitizen" :{ "path" : "node_modules/cz-conventional-changelog" } } Copy code

If it is a global installation, complete the above configuration, you can use

git cz
Order, you can
packge.json
Configured command
npm run commit
Make a submission

The following are further restrictions on the submission specification

  • use
    Husky
    generate
    Git Hooks

Husky is responsible for providing easier-to-use git hooks. Combine git hook to check the commit message, so that when your submission does not conform to the specification, it will prevent you from submitting

npm i -D husky duplicated code

Note that because the versions of husky4.0 and husky6.0 are quite different, and the configuration methods are also different, so the distinction is introduced

  1. husky4.0
    Version configuration
    package.json
    Add the following configuration
"husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } } Copy code

git hooks
Is to execute git -commit -m "xxx" in the project is the trigger
commit-msg
Time hook and notify husky to execute
commitlint -E HUSKY_GIT_PARAMS
Command and it will read
commitlint.config.js
Configure and verify the information we submitted. If the verification fails, then
commit
termination

  1. husky6.0
    Version not configured
    package.json
    File, use the command to generate instead
    .husky
    folder

Install and initialize

husky

npx husky-init duplicated code

Will be generated under the root path of the current project

.husky
Folder and
pre-commit
File while
package.json
Will add code

"scripts": { "prepare": "husky install" } Copy code

Enable Git hook

npx husky install or pm run prepare Copy code

Only install globally

husky
In order to run the following command to generate
commit-msg
file

husky add .husky/commit-msg " npm test" copy the code

Otherwise

.husky
Create manually under
commit-msg
file

Generate or add

commit-msg
After the file, and modify the content to the following

#!/bin/sh . "$(dirname "$0")/_/husky.sh" yarn commitlint --config commitlint.config.js --edit $1//Only this sentence needs to be modified Copy code

Install other git hooks only need to execute

husky add .husky/hook name "npm test"
That's it

Then run

git add. git commit -m "test commit"//If the submission is not standardized, it can be verified Copy code
  • Custom specification

If you want to define the submission specification yourself, you must first download the package that is constrained by the custom specification to replace the third-party specification.

npm i -D commitlint-config-cz cz-customizable duplicated code

Created in the project root directory

.cz-config.js
, You can customize the specification in this file (the following is my customized configuration)

module .exports = { types : [ { value : 'init' , name : 'init: initial submission' }, { value : 'feat' , name : 'feat: add new features' }, { value : 'fix' , name : 'fix: fix bug' }, { value : 'ui' , name : 'ui: update UI' }, { value : 'refactor' , name : 'refactor: code refactoring' }, { value : 'release' , name : 'release: release' }, { value : 'deploy' , name : 'deploy: deployment' }, { value : 'docs' , name : 'docs: modify document' }, { value : 'test' , name : 'test: add/delete test' }, { value : 'chore' , name : 'chore: change configuration file' }, { value : 'style' , name : 'style: style modification does not affect logic' }, { value : 'revert' , name : 'revert: version rollback' }, { value : 'add' , name : 'add: add dependency' }, { value : 'minus' , name : 'minus: version rollback' }, { value : 'del' , name : 'del: delete code/file' } ], scopes : [ { name : 'components' }, { name : 'utils' }, { name : 'styles' }, { name : 'deps' }, { name : 'other' } ], messages : { type : 'Select the type of change:\n' , //If allowcustomscopes is true, use scope : 'Select a scope (optional):\n' , customScope : 'Please enter a custom scope:' , subject : 'Short description:\n' , body : 'Detailed description. Use "|" to wrap:\n' , breaking : 'Breaking Changes list:\n' , footer : 'Closed issues list. Eg: #31, #34:\n' , confirmCommit : 'Confirm Commit?' }, allowCustomScopes : true , allowBreakingChanges : [ 'feat' , 'fix' ] } Copy code

package.json
Modified to, custom specification

//Use "config" for custom specifications : { "commitizen" : { "path" : "node_modules/cz-customizable" } } //Or "config" : { "cz-customizable" : { //You can rename .cz-config.js "config" : "config/config.js" } } Copy code

cz-customizable
1. it will look for a file named
.cz-config.js
or
.config/cz-config.js
If the file cannot be found, it will look in the home directory
.cz-config.js
or
.config/cz-config.js
or
package.json
. (Refer to the official website translation...)

commitizen
: The default is to use the above
.cz-config.js
File, if you want to
.cz-config.js
To rename the file, use
cz-customizable
Configuration

  • Don t forget to modify
    .czrc
    The content of the file is a custom specification

{"path":"cz-customizable"} Copy code
  • Supplement: Verify the content of `git commit -m "xxx" message

If you want to use ``git commit -m "xxx"` and verify the content of this name, you need to do the following

npm i -D @ commitlint/config- conventional @ commitlint/cli duplicated code

commitlint is responsible for format verification of the commit message.

  • Configuration
    commitlint.config.js
    file

Create new under the project and path

commitlint.config.js
file
rules
In order to customize the rules, two specifications are used at the same time, you can just
cz
or
@commitlint/config-conventional
one of

  • cz
    : Custom specifications
  • @commitlint/config-conventional
    : Specification used by the Angular team
  • extends: [Specification List]
    Multiple specifications can be used at the same time

This file is right

git commit -m "xxx"
content
xxx
Check,

module .exports = { extends : [ '@commitlint/config-conventional' , 'cz' ], rules : { // Header'header -max-length' : [ 2 , 'always' , 200 ], //<type > Enumeration'type -enum' : [ 2 , 'always' , [ 'add' , //add dependency'delete ' , //delete code/ file'feat' , //add new function'fix ' , //fix bug'style' , //style modification does not affect logic'merge' , //merge branch'perfect' , //function perfect'docs' , //modify document'refactor ' , //code refactoring'test ' , //unit test modification'ci ' , //continue to inherit'release' , //release 'deploy' , //deploy 'Chore' , //change the profile 'revert' //version rollback ] ], //<type> cannot be empty'type-empty' : [ 2 , 'never' ], //<type> format lowercase'type -case' : [ 2 , 'always' , 'lower-case' ], //<scope> cannot be empty , 'never' , '.' ], //<subject> format //optional value //'lower-case' lowercase lowercase //'upper-case' uppercase UPPERCASE //'camel -case' little camel case camelCase //'kebab-case' dash kebab-case //'pascal-case' big camel case PascalCase empty'scope-empty' : [ 2 , 'never' ], //<scope> format lowercase'scope -case' : [ 2 , 'always' , 'lower-case' ], //<subject> cannot be empty'subject-empty' : [ 2 , 'never' ], //<subject> end with. as the end sign'subject-full-stop' : [2 1 //'sentence-case' first letter capitalized Sentence case //'snake-case' underscore snake_case //'start-case' Capitalize all first letters start- case'subject-case' : [ 2 , 'never' , []], //<body> starts with a blank line'body-leading-blank' : [ 1 , 'always' ], //<footer>Start with a blank line'footer-leading-blank' : [ 'always', ] } } Copy code

The above is a relatively complete verification, and the above can also be combined for verification in different scenarios. Please refer to this blog . Thank you for this blogger too!

Reference materials:
Introduction to the use of Cz toolset on the husky
cz-customizable
blog
-Standard Git submission