Git Commit specification for multi-party collaboration

Blog address

preface

Multi-person collaboration projects are common in daily work, and multi-person collaboration usually requires some kind of specification. Tools like ESLint, TSLint, Stylelint, Prettier, etc., are known to help teams unify code level specifications, as well as commit code, which is an integral part of front-end engineering

The format of the commit is key: value. The key is a function module, and the value is a description of specific changes

A good COMMIT specification provides clear changes to modules, messages, and logs. The Angular specification is widely accepted in the industry, so let’s take a look

specification

A commit messgae consists of three parts: Header, Body, and Footer, where Header is mandatory

• Header

Header contains type, scope, and subject

Type. In addition to the following types, you can also customize the types for your project

Scope: The scope or module involved in this commit (e.g. Package.json)

Subject: Describes the change

• Body

The Body is a detailed description of this change

• Footer

Footers are notes, usually links to BREAKING CHANGE or bug fixes

Commitizen

Commitizen is a Commit message tool that helps us a lot

The installation

npm install Commitizen -g
Copy the code

Start project execution after installation (Node project)

commitizen init cz-conventional-changelog --save --save-exact
Copy the code

Git cz: git cz: git cz: git cz: git cz: git cz

Select the commit type and press Enter. The following steps follow:

# Fill in the scope of impact of this change and continue
What is the scope of this change (e.g. component or file name): (press enter t
o skip)

Copy the code

# Write a short description. Go on
 Write a short, imperative tense description of the change (max 88 chars)
Copy the code

# Elaborate. Move on
Provide a longer description of the change
Copy the code

# is it BREAKING CHANGE
Are there any breaking changes
Copy the code

No return is available
Does this change affect any open issues
Copy the code

Now we have completed a standard commit, git log:

Author: sf_cxw <[email protected]> Date: Thu Jul 23 12:06:32 2020 +0800 Feat (User Management): Add a blacklist and whitelistCopy the code

Commit check

Getting back to the issue of git commit usage irregularities, we need to add validation to commit messages

Install @commitlint/ CLI, @commitlint/ config-Conventional

npm|cnpm install @commitlint/config-conventional @commitlint/cli -D
Copy the code

Generate commitlint.config.js, or optionally configure it yourself in commitlint.config.js

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

husky

How to trigger checksum?? Git /hooks are the scripts that trigger the execution of certain events (commit, push, etc.) in Git. The.sample extension prevents them from being executed by default. The same is true for ESLint and stylelint checks when submitting code.

Using husky here to help us with the validation, husky installation will generate the hooks we need in the.git/hooks directory.

The installation

npm|cnpm install husky -D
Copy the code

The installation is successful, as shown in the image above

Add it to package.json after installation

"husky": {
    "hooks": {
      "pre-commit": "lint-staged", // Here is your esLint, stylelint, etc checksum, no configuration required"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}Copy the code

The commit verification has already been configured

$ git commit -m '1'Husky > commit- MSG (node v10.16.0) cataplexy? Input: 1 ð ¨ plus or minus Subject may not be empty [subject-empty] ð¨type may not be empty [type- the empty] ð ¨ plus or minus Found 2 problems, 0 warnings cymbals? Gethelp: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky > commit-msg hook failed (add --no-verify to bypass)

Copy the code

Now it is no longer possible to commit code without following the specification

$ git commit -m 'Fix: Fixed 10,000 bugs'Husky > commit-msg (node v10.16.0) [master (root-commit) 79f5922] fix: husky > commit-msg (node v10.16.0) [master (root-commit) 79f5922] fix: Bug 4 Files changed, 2001 insertions(+) create mode 100644 .gitignore create mode 100644 commitlint.config.js create mode 100644 package-lock.json create mode 100644 package.jsonCopy the code

Git cZ instead of git COMMIT

Logs and Versions

As mentioned above, a good COMMIT specification can also provide good logging, such as Convention-Changelog, but we have a better option: standard-version

In addition to helping us generate logs, standard-version also helps us control project versioning and tag

Global installation

npm|cnpm install standard-version -g
Copy the code

Package. Join in json

"scripts": {
    "release": "standard-version --release-as"."release:100": "npm run release -- major"."release:010": "npm run release -- minor"."release:001": "npm run release -- patch"
}
Copy the code

• Major: indicates the major version
• Minor: indicates the second version
• Patch: Revised version
• Release: Custom version NPM run release — 1.0.0
• Release :100: Execute the script, and if the current version is 1.0.0 the version will be promoted to 2.0.0
• Release :010: Execute the script, and if the current version is 1.0.0 the version will be upgraded to 1.1.0
• Release :001: Execute the script, and if the current version is 1.0.0 the version will be upgraded to 1.0.1

After the preceding command is executed, three actions are performed: version generation, tag generation, and log generation. Logs are stored in Changelog. md

$git tag v1.0.1 v1.0.2 v2.0.0Copy the code

The actual effect of the log is seen in the chase travel blog log

conclusion

Joy: Joy: Joy: