Submit specification environment setup

Why standardize Git commit

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

The spec Git reference uses the following dependent plug-ins. Here are the ones I used and their version numbers

  • "Commitizen" : "^ holdings", // Commitizen is a tool to help write normative Commit messages
  • Cz - but - changelog: "^ 3.3.0"// Adaptor, which is used to provide the convention submission format. Different adaptors can be used for different requirements
  • "@ commitlint/config - but", "^ 12.1.1." ", // Community-defined submission specifications
  • "@ commitlint/cli" : "^ 12.1.1." "// A command line tool to verify submission informationThe document
  • "Commitlint - config - cz" : "^ 0.13.2", // for custom submission formats
  • Cz - customizable: "^ 6.3.0", // Customize submission specification prompt copy
  • "Husky" : "^ 6.0.0"// Husky is a Git Hook tool. Husky is a tool that adds hooks to Git clients

There are two ways to do this:

  • Global installation, using the convention specification submission format provided by a third party
  • The project is installation-dependent and commits using custom specification conventions

The first is global installation

  • Install dependencies

npm i -g commitizen cz-conventional-changelog
Copy the code

  • generate.czrcfile

    Run echo ‘{“path”:” CZ-conventional – Changelog “}’ > ~/. CZRC to generate the. CZRC file in the root path and specify an Adapter for Commitizen.

    Note: If the installation is global

    • mac OSThe following command can be executed directly echo '{"path":"cz-conventional-changelog"}' > ~/.czrcIt’s going to be generated in the following path.czrcfile
    • windowRun the following command directlyecho '{"path":"cz-conventional-changelog"}' > ~/.czrcThis command will return an error because~ /isLinuxThe command represents the root pathwindowGenerated in the root path.czrcThe command of this file, I am not quite clear, also do not know inwindowThe next heel path refers to that path

  • configurationpackage.json

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

Git cz. You can also configure packge.json and run NPM run commit

The second is project-dependent installation

  • Install dependencies

npm i -D commitizen cz-conventional-changelog
Copy the code

Run echo ‘{“path”:” CZ-Conventional – Changelog “}’ >. CZRC to generate the. CZRC file in the current path and specify an Adapter for Commitizen.

Note: The single quotes in the.czrc file need to be removed

Add the following configuration to the package.json file

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

Git cz or packge.json NPM run commit

The following further constrains the submission specification

  • useHuskygenerateGit Hooks

Husky is responsible for providing git hooks that are easier to use. Verify the commit message with git hooks so that it will block you from committing if your commit does not conform to the specification

npm i -D husky
Copy the code

Note that husky4.0 and husky6.0 are different versions and configurations

  1. husky4.0Version of the configurationpackage.jsonAdd the following configuration
"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
}
Copy the code

Git-commit -m “XXX” is used to trigger commit-msg time hooks and notify husky to execute commitlint -e HUSKY_GIT_PARAMS. It reads the commitlint.config.js configuration and validates our commitlint.config.js. If validation fails, commit terminates

  1. husky6.0Version not configuredpackage.jsonFile, using command generation instead.huskyfolder

Install and initialize Husky

npx husky-init
Copy the code

Husky folder and pre-commit files will be generated in the current project root path, and package.json will add code

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

Enabling Git hooks

NPX husky install or PM run prepareCopy the code

Only a global husky installation can run the following command to generate the commit-msg file

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

Otherwise, manually create the commit- MSG file under.husky

After generating or adding the commit- MSG file, 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 modifiedCopy the code

To install other Git hooks, simply execute husky add. husky/ hook name “NPM test”

Then run

Git add. Git commit -m "test commitCopy the code

  • Custom specification

If you want to define your own submission specification, you can download the package of the custom specification constraints to replace the third-party specification.

npm i -D commitlint-config-cz cz-customizable
Copy the code

Create.cz-config.js in the project root directory and you can customize the specification in this file (here is my custom configuration).

module.exports = {
	types: [{value: 'init'.name: 'Init: Initial commit' },
		{ value: 'feat'.name: 'Feat: Add New Features' },
		{ value: 'fix'.name: 'fix: fix bugs' },
		{ value: 'ui'.name: 'update UI: UI' },
		{ value: 'refactor'.name: 'Refactor: Code refactoring' },
		{ value: 'release'.name: 'released release: },
		{ value: 'deploy'.name: 'the deploy: deploy' },
		{ value: 'docs'.name: 'docs: Modify document ' },
		{ value: 'test'.name: 'test: Add/delete test ' },
		{ value: 'chore'.name: 'chore: Changing the Configuration File ' },
		{ value: 'style'.name: 'style: Style changes do not affect logic ' },
		{ value: 'revert'.name: 'Revert: Version Rollback' },
		{ value: 'add'.name: 'Add: Add dependencies' },
		{ 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 change type :\n'.// If allowCustomscopes are true, use them
		scope: Select a scope (optional) : \n'.customScope: 'Please enter custom scope:'.subject: 'Brief description :\n'.body: 'described in detail. The use of "|" line: \ n'.breaking: 'Breaking Changes list :\n'.footer: 'List of closed issues. E.g.: #31, #34:\n'.confirmCommit: 'Confirm submission? '
	},
	allowCustomScopes: true.allowBreakingChanges: ['feat'.'fix']}Copy the code

package.jsonModify to custom specifications

// If custom specifications are used
"config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"}}/ / or
"config": {
    "cz-customizable": { // You can rename.cz-config.js
        "config": "config/config.js"}}Copy the code

Cz-customizable will first look for a file named. Cz-config. js or. Config /cz-config.js in the project root directory. It will look in the home directory for.cz-config.js or.config/cz-config.js or package.json. (Refer to the official website translation…)

Commitizen: The default is the above.cz-config.js file. If you want to rename the.cz-config.js file, use the CZ-customizable configuration

  • Don’t forget to revise at the end.czrcThe contents of the file are user-defined specifications

{"path":"cz-customizable"}
Copy the code

  • Git commit -m “XXX” message

If you want to use ‘ ‘git commit -m “XXX” and verify the contents of this name, you need to do the following

npm i -D @commitlint/config-conventional @commitlint/cli
Copy the code

Commitlint is responsible for formatting the COMMIT message.

  • configurationcommitlint.config.jsfile

New commitlint.config.js file rules for custom rules, both specifications are used here. You can use either CZ or @commitlint/ config-Conventional

  • cz: Custom specification
  • @commitlint/config-conventional: specification used by the Angular team
  • Extends: [List of specifications]Multiple specifications can be used simultaneously

Git commit -m “XXX”

module.exports = {
	extends: ['@commitlint/config-conventional'.'cz'].rules: {
		// Header
		'header-max-length': [2.'always'.200]./ / < type > enumeration
		'type-enum': [
			2.'always'['add'.// Add dependencies
				'delete'.// Delete code/files
				'feat'.// Add new functionality
				'fix'./ / fix the bug
				'style'.// Style changes do not affect logic
				'merge'.// Merge branches
				'perfect'.// Complete functionality
				'docs'.// Modify the document
				'refactor'.// Code refactoring
				'test'.// Unit test modification
				'ci'.// continuous inheritance
				'release'./ / release
				'deploy'./ / deployment
				'chore'.// Change the configuration file
				'revert' // Version rollback]],// 
      
        cannot be empty
      
		'type-empty': [2.'never'].// 
      
        in lowercase format
      
		'type-case': [2.'always'.'lower-case'].// 
      
        cannot be empty
      
		'scope-empty': [2.'never'].// 
      
        in lowercase format
      
		'scope-case': [2.'always'.'lower-case'].// 
      
        cannot be empty
      
		'subject-empty': [2.'never']./ / < subject > in. For closing mark
		'subject-full-stop': [2.'never'.'. ']./ / < subject > format
		/ / optional value
		// 'lower-case' lowercase lowercase
		// 'upper-case' UPPERCASE
		// 'camel-case' camelCase
		// 'kebab-case' short line kebab-case
		// 'pascal-case' PascalCase
		// 'sentence-case' uppercase sentence case
		// 'snake-case' underline snake_case
		// 'start-case' uppercase all letters start-case
		'subject-case': [2.'never'[]],//  starts with a blank line
		'body-leading-blank': [1.'always'].// 
      

        starts with a blank line
      

		'footer-leading-blank': [1.'always']}}Copy the code

The above is a more complete check, can also be combined on the above, for different scenarios of the check, please refer to this blog, here also thank the blogger friend!

Resources: Husky CZ-CustomIZABLE Blog CZ Toolset Usage Introduction – Specification Git submission instructions