For the same project, in order to facilitate management, the commit information of git should preferably be standardized in a certain format, so that it can be easily used when needed. When it is convenient, for example, an online bug occurs, so you need to roll back the operation. Knowing the submission information can easily locate the problem. When the code is reviewed, I also know what the commit did, so there are many benefits of commit standardization, so I won't give an example.
accomplish
What can be immediately thought of is to use the shell combined with git hook to check whether the input conforms to the specification in the git commit phase. If it conforms, it will be passed, if not, it will be terminated, and a prompt message will be given.
what is the norm
Common categories are as follows:
- build: The submission of the build system (xcodebuild, webpack, glup, etc.) that modifies the project
- ci: commits that modify the project's continuous integration process (Kenkins, Travis, etc.)
- chore: changes to the build process or auxiliary tools
- docs: document submission (documents)
- feat: new feature (feature)
- fix: fix bug
- pref: submissions related to performance and experience
- refactor: code refactoring
- revert: roll back an earlier commit
- style: code modification that does not affect program logic, mainly style optimization and modification
- test: test related development
wheel
There is a commitlint project on github , which can be easily configured in the project, and allows you to customize the "standard" and "classification" mentioned above.
commitlint : for checking commit information husky : hook tool for git-commit and git-push phases.
how to use?
- Initialize a node project:
npm init -y
- Install required dependencies.
npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
- Create a new configuration file in the project root directory with the name
commitlint.config.js
. - Add configuration information in commitlint.config.js
const types = [ 'build', 'ci', 'chore', 'docs', 'feat', 'fix', 'pref', 'refactor', 'revert', 'style', 'test' ]; typeEnum = { rules: { 'type-enum': [2, 'always', types] }, value: () => types } module.exports = { extends: [ "@commitlint/config-conventional" ], rules: { '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], 'type-enum': typeEnum.rules['type-enum'] } };
- Add the following code to the package.json file at the same level as devDependencies .
"husky": { "hooks": { "pre-commit": "echo '哈喽,小伙伴们,在这里可以做测试相关的逻辑哦,一般结合公司的 ci'", "commit-msg": "commitlint -E HUSKY_GIT_PARAMS", "pre-push": "echo 提交代码前需要先进行单元测试 && 可以做测试相关" } }
The above process configuration is completed. When you submit the input content of the commit information, if it does not meet the <type>: <subject>
rules , it will be terminated and a prompt message will be given.
type is the above category; subject is the textual summary that needs to be submitted. For example: feature: Add the function of shaking and recommending hotels.
Small note: If you want to disable husky in a commit, you can add the parameter --no-verify .git commit --no-verify -m "xxx"
Paste a rendering
Flow Description
When the package husky is installed, a bunch of shell scripts will .git/hooks/
be , responsible for git hooks.
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
This configuration tells git hooks git commit -m
to , and notify husky to execute commitlint -E HUSKY_GIT_PARAMS
it. In fact, what is executed is ./node_modules/husky/bin/run.js
to read the configuration in commitlint.config.js, and then write to the string in our commit -m Check, if it fails, output an error message and terminate.
Expansion
Several hooks of git commit are also exposed, so you can do some additional logic in combination with the timing.
- pre-commit: Triggered before git commit
- commit-msg: Triggered when writing commit information
- pre-push: trigger before git push
So based on the above timing, you can do something else according to the characteristics of the project. Such as code lint, unit test code coverage detection, changelog automatic generation, unit test script, etc., you can also take this opportunity to generate lint reports