The commit message should be clear and clear, stating the purpose of the commit. However, many people will simply write git messages when submitting git information for convenience, for development and maintenance of crematoria. With a clear and consistent submission style that facilitates team collaboration and maintenance, this article shares our guidelines for limiting code submission.

Configure your own submission specification

/ / commitizen installation
npm install -g commitizen

// Commitizen configures the commit message according to the different adapter
npm install -g cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
Copy the code

Configuration is completed, in you enter any local git repository, use the git cz instead of git will be the option to commit, used to generate conform to the format of the commit message, the following figure:

2. Custom submission specifications

The following is a custom submission specification for projects with global configuration references: this big guy article

To customize the submission specification, we need to use CZ-Customizable.

Cz-customizable is a Commitize N adapter, just like CZ-Conventional – Changelog. However, CZ-Customizable supports some degree of customization

  1. Install NPM I CZ-customIZABLE –save-dev

  2. Add the following configuration to package.json

    "config": {
   "commitizen": {
     "path":"node_modules/cz-customizable"}}Copy the code

  3. Create the.cz-config.js custom prompt file in the project root directory

    module.exports = {
  // Optional type
  types:[
    { value: 'feat'.name: 'Feat: New Feature'},
    { value: 'fix'.name: 'fix: fix'},
    { value: 'docs'.name: 'docs: Document changes'},
    { value: 'style'.name: 'style: code format (changes that do not affect code execution) '},
    { value: 'refactor'.name: 'Refactor: Refactoring (neither adding features nor fixing bugs)'},
    { value: 'pref'.name: 'PreF: Performance Tuning'},
    { value: 'test'.name: 'test:      增加测试'},
    { value: 'chore'.name: 'chore: Changes to the Build process or accessories'},
    { value: 'revert'.name: 'revert: back'},
    { value: 'build'.name: 'build: package'}]./ / steps
  messages: {
    type: 'Please select the type of submission; '.customScope: 'Please enter modified range (optional)'.subject: 'Please briefly describe submission (required)'.body: 'Please enter a detailed description (optional)'.footer: 'Please select issue to close (optional)'.confirmCommit: 'Are you sure you want to submit using the above information? (y/n)"
  },

  // Skip the step
  skip: ['body'.'footer'].// The default length
  subjectLimit: 72
}
Copy the code

  4. At this point, when executing Git CZ, we can fill in the option information according to the self-configured specification, as shown in the following figure

Husky + Git hooks

  1. Git Hooks

There are a lot of hooks overall, but there are only two that we use the most

  1. commit-msg
    • bygit commit 和 git mergecall
    • You can usegit commit --no-verifybypass
  2. pre-commit
    • bygit commitcall
    • You can usegit commit --no-verifybypass
    • Called before getting the suggested commit log message and committing
  1. husky

Git Hook husky is a Git Hook tool

1, use,husky + commitlintCheck that the submitted message conforms to the specification

Git cZ: Git cZ: Git CZ: Git CZ: Git CZ: Git CZ: Git CZ

If you forget to use git cz and use git commit -m “my commit”, the message will still be committed, and the project will have an improper commit message

Therefore, we need husky + commit-msg + commitLint to verify that our commit information is normal.

Install and configure CommitLint

  1. NPM install –save-dev @commitlint/config-conventional @commitlint/cli

  2. Create the commitlint.config.js file

    module.exports = {
  extends: ['@commitlint/config-conventional'].// Define the rule type
  rules: {
    // Type definition, which means git must submit a type within the following type range
    'type-enum': [
      2.'always'['feat'./ / new features
        'fix'./ / repair
        'docs'.// Document changes
        'style'.// Code format (changes that do not affect code execution)
        'refactor'.// Refactoring (neither adding features nor fixing bugs)
        'pref'.// Performance optimization
        'test'.// Add tests
        'chore'.// Changes to the build process or accessibility tools
        'revert'./ / back to back
        'build' / / packaging]],// Subject case is not checked
    'subject-case': [0]}}Copy the code

    Note: This file needs to be saved in UTF-8 format, otherwise errors may occur

Install and configure Husky

  1. Install depends on NPM install husky –save-dev

  2. Start hooks to generate.husky folder NPX husky install

  3. NPM set-script prepare “husky install”

    Note: this requires NPM > 7.0 and you can use NPM install -g NPM upgrade

  4. Run the prepare command NPM run prepare

  5. Add commitlint hooks to husky and verify at commit-msg

    npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

    After adding:

  6. At this point, non-conforming commits will not be allowed, and we are done! The test is shown below:

2. Pre-commit checks whether the current code has ESLint errors

We expect NPX esLint — ext.js,.ts,.vue SRC directives to check code specification before it is submitted

The pre – commit detection

  1. NPX esLint — ext. js,.ts,.vue SRC for pre-commit

    npx husky add .husky/pre-commit "npx eslint --ext .js,.ts,.vue src"

    The results are shown below:

  2. At this point, the code is submitted, and if there is an error in the project that cannot be submitted, in order to submit the code, you must resolve all the error messages

Lint-staged automatically fixes formatting errors

Lint-staged code inspection allows your current code review to examine only the code that has been modified or updated this time, and automatically fix and push errors when they occur

Lint-staged installation is unnecessary; VUE-CLI did it for us when building projects

  1. Modify package.json configuration

    "lint-staged": {
 "src/**/*.{js,ts,vue}": [
   "eslint --fix",
   "git add ."
 ]
}
Copy the code

  2. As configured above, each time it verifies that your content complies with your locally configured ESLint rules before committing locally

    1. The submission is successful
    2. If it doesn’t, he’ll do it automaticallyeslint --fixTry to help you automatically fix 2.1, it will automatically help you to submit the repaired code; 2.2 Failed to repair, you will be prompted with an error, so that you can only submit the code after repair;

  3. Configure the.husky/pre-commit file

    #! /bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged
Copy the code