Git submission information of standardization team


For the same project, in order to facilitate management, GIT’s commit information should be standardized according to certain format, so as to be convenient to use when necessary. What is convenient? For example, there is an online bug, so you need to roll back. Knowing the submission information can easily locate the problem. During the code review, we also know what the commit has done. Therefore, there are many benefits of commit standardization, so we will not give examples.


You can immediately think of using shell combined with git hook to check whether the input conforms to the specification in Git commit phase. If it meets the requirements, it will pass, and if it does not, it will be terminated.

What is the norm

The common classifications are as follows:

  • Build: modify the submission of the project’s build system (xcodebuild, webpack, GLUP, etc.)
  • The process of continuous modification of project (kencis)
  • Choose: changes in the construction process or AIDS
  • Documents: Documents
  • Feature: new feature
  • Fix: fixing bugs
  • Pref: performance and experience related submission
  • Refactor: code refactoring
  • Revert: rolls back an earlier commit
  • Style: code modification without affecting program logic, mainly optimization and modification of style
  • Test: test related development


There is a commitlint project on GitHub, which can be easily configured in the project, and allows you to customize the “specification” and “classification” mentioned above.

Commitlint: used to check the submission information
Husky: hook tool for git commit and git push phases.

How to use it?

  1. Initialize a node entry:npm init -y
  2. Install the required dependencies.npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
  3. Create a new configuration file in the root directory of the projectcommitlint.config.js
  4. In commitlint.config.js Add configuration information in

    const types = [
    typeEnum = {
      rules: {
        'type-enum': [2, 'always', types]
      value: () => types
    module.exports = {
        extends: [
        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. In package.json Add the following code to the file. The code level followsdevDependenciesThe same level.

    "husky": {
        "hooks": {
            "Pre commit": "echo 'Hello, guys, you can do test related logic here, generally combined with the company's Ci'",
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
            "Pre push": "echo unit test is required before code submission

The above process configuration is completed. When you submit the input content of commit information, if it does not match the<type>: <subject>Rule, will terminate and give a prompt message.

Type is the above category; subject is the text summary to be submitted. For example: feature: add the function of rocking and recommending hotels.

If you want to disable husky in a submission, you can add parameters–no-verifygit commit --no-verify -m "xxx"

Paste an effect picture

Git submission information of standardization team

Process description

When installing the husky package, the.git/hooks/Generate a bunch of shell scripts, responsible for git hook.

"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"This configuration tells git hooks thatgit commit -mThe commit MSG hook is triggered and husky is notified to executecommitlint -E HUSKY_GIT_PARAMSWhat is actually implemented is./node_modules/husky/bin/run.js, read commitlint.config.js Then check the string in commit – M. if it fails, it will output an error message and terminate.


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 a commit message is written
  • Pre push: triggered before git push

So based on the above timing, you can do something else according to the characteristics of the project. For example, code lint, unit test code coverage detection, automatic generation of changelog, unit test script, etc., can also take this opportunity to generate lint reports