Normalize team git commit information

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?

1. Initialize a node project:npm init -y
2. Install required dependencies.npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
3. Create a new configuration file in the project root directory with the name commitlint.config.js.
4. 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']
       }
     };
   

5. 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 -mto , and notify husky to execute commitlint -E HUSKY_GIT_PARAMSit. In fact, what is executed is ./node_modules/husky/bin/run.jsto 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

{{o.name}}

{{m.name}}