Simply use commit - to standardize your commit message

Keywords: git

Recently, I used git to develop the learning specification and found a relatively easy-to-use tool to standardize comments. Record it. Generally speaking, the commit message should be clear and explain the purpose of this submission, so some specifications are needed to make these comments readable. Commit is a relatively easy-to-use tool recently found

Git commit uses git commit -m "hello world" to submit comments, but some meaningless comments like hello world make people unable to understand what the submission is for
Here are some basic introductions. If you feel troublesome, please check the second part directly

1. Commit message format

The commit message is generally divided into three parts: Header, Body and Footer

<type>(<scope>): <subject>
// One blank line
// One blank line
Among them, Header Is required, Body and Footer Can be omitted

PS D:\git\pythonPractice> git log
commit 58a7a966acb9aa2fffc0e02c9ce3be64b8949991 (HEAD -> master)
Author: Zhiwei Tian <>
Date:   Fri Aug 17 17:38:36 2018 +0800

    feat(serve): add grpc server

1.1 HEAD

  • type is used to describe the category of commit. Only the following 7 identifiers are allowed

feat: New features( feature)
fix: repair bug
docs: Documentation( documentation)
style:  Format (changes that do not affect code operation)
refactor: Refactoring (i.e. neither new nor modified) bug (code change of)
test: Add test
chore: Changes in the construction process or auxiliary tools
  • Scope is used to describe the scope of the impact of this Commit, that is, to briefly describe the parts involved in the modification, such as data layer, control layer, view layer, etc,
  • The location of the subjectcomment, and a brief description of this submission

1.2 Body is a detailed description of this commit, which can be divided into multiple lines

1.3 the footer section is only used in two cases

  • Incompatible changes

If the current code is incompatible with the previous version, the Footer section starts with BREAKING CHANGE, followed by a description of the change, the reason for the change and the migration method

  • Close Issue

If the current commit is for an issue, you can close the issue in the Footer section (you can close issuecloses #123, #245, #992 in turn)

1.4 Revert

In another special case, if the current commit is used to revoke the previous commit, it must start with revert: followed by the Header of the revoked commit

revert: type(scope):  some comment
This reverts commit bfe307ce57d87677c6c473c228e6c2ed8b81dcec.

The format of the Body part is fixed and must be written as this reverses commit < hash >, where hash is the HSHA identifier of the revoked commit.
If the current commit and the revoked commit are in the same release, they will not appear in the Change log. If they are in different releases, the current commit will appear under the Reverts subheading of the Change log

2. Use commit to execute the specification

If required node (download address on the official website)
If you see EACCES errors, read fixing npm permissions Get help)
The following operations refer to the instructions given by CZ cli warehouse. For more detailed information, please go to cz-cli.

  1. Globally install the commitizennode module

npm install -g commitizen

If your project is not a node project, the following contents can be ignored directly. Please turn directly to the first level title 3

  1. Run the command in the project directory

commitizen init cz-conventional-changelog --save --save-exact
  1. At this time, an error that package.json cannot be found may be reported. Use the following command to automatically generate a project package, and then run the command in 2

npm init --yes

After running the above, always use git cz instead of git commit to submit the code. At the same time, the following options will be displayed to automatically generate a commit message that conforms to the format

PS ~/git> git cz
cz-cli@2.10.1, cz-conventional-changelog@2.1.0

Line 1 will be cropped at 100 characters. All other lines will be wrapped after 100 characters.

? Select the type of change that you're committing: (Use arrow keys)
> feat:     A new feature
  fix:      A bug fix
  docs:     Documentation only changes
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  refactor: A code change that neither fixes a bug nor adds a feature
  perf:     A code change that improves performance
  test:     Adding missing tests or correcting existing tests
(Move up and down to reveal more choices)

Follow the prompts and you can write a standard message
idea has plug-ins to use git commit template (science ~ learning may be required to access the Internet)

Commit can also check whether the commit message conforms to the format
Generate change log, and some advanced usage, such as ghooks
I won't elaborate here. For details, please see the reference links and validate-commit-msg

  1. dir:node_nodules, file:package.json, package-lock.json and other directories and files may be added to the project. These directories and files are generated by the node installation module. If they are not node projects, they can be ignored. Students familiar with node must know what is useful

3. Use git CZ gracefully in non node projects

Here you can install git CZ in the context of 2.1

npm install -g commitizen git-cz

You can also customize some content with git CZ adapter, and some expressions will be attached by default, as shown in the following figure
Please refer to warehouse for detailed settings git-cz Details given


Reference link:
Ruan Yifeng Blog
Jartto's blog

Author: TinChiWay
Source: Jianshu
The copyright belongs to the author. For commercial reprint, please contact the author for authorization. For non-commercial reprint, please indicate the source.

Posted by Pavel_Nedved on Tue, 09 Nov 2021 14:34:06 -0800