As the team continues to expand, git's commit information needs to follow a certain format specification to facilitate use when needed. Submitting information can easily locate the problem. When reviewing the code, I also know what the commit did, so the standardization of commit has many advantages, so I wo n’t say more.
achieve
结合 git hook 实现在 git commit 阶段检查输入是否符合规范，符合通过，反之提示
tool
commitlint: used to check the commit information, define "standard", "classification"
husky: hook tool, used in git-commit and git-push phase
specification
The common types according to commitlint-config-conventional (based on Angular conventions) are as follows:
build: modify the project's build system (xcodebuild, webpack, glut, etc.) submission •
ci: modify the project's continuous integration process (Kenkins, Travis, etc.) submission
chore: build process or auxiliary tool changes •
docs: document submission ( documents)
feat: new feature (feature)
fix: fix bugs •
perform: performance and experience-related commit
refactor: code refactoring
revert: roll back an earlier commit •
style: code modification that does not affect program logic, main It is the optimization and modification of style
: test-related development
Not recommended
If you want to disable verification for a certain submission, you can add the parameter --no-verify. git commit --no-verify -m "xxx"
