In daily development work, git is usually used to manage the project code. After the code is modified, the code can be submitted through the git commit command.
Git stipulates that the submission information must be written when submitting, as a description of the change, and saved in the commit history for easy retrospection. The standardized log is not only helpful for others to review, but also can effectively output CHANGELOG, and even greatly improves the quality of the project's research and development.
However, in daily work, most students simply write and write log information and do not pay much attention to it. This is undoubtedly unfriendly for project management and maintenance. This article is mainly based on my own experience to share some specifications of git commit with you, so that your log is not only "good-looking" but also "practical".
Why should we standardize the commit message? It
has been said that we should standardize the format of the commit message, so why should we do this?
Let's first look at a non-standard commit record: 
how do you feel after reading it, what has been updated in the end, it is all written update, this kind of commit information is undoubtedly one for those who want to obtain valid information A fatal blow.
Then let's take a look at the commit record of the more popular Angular specification in the community: 
Is it clear after reading it?
The standardized commit information in the above figure firstly provides more historical information for quick browsing. Secondly, certain commits (such as document changes) can be filtered to facilitate quick search of information.
Now that the Angular team's specification is the most popular commit specification in the community, what exactly is it? Let's take a closer look at it.
The Angular team's commit specification and
its message format are as follows:
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>Corresponding to the three parts of the Commit message: Header, Body and Footer.
Header The
Header part has only one line, including three fields: type (required), scope (optional), and subject (required).
type: Used to indicate the type of commit. Generally there are the following:
feat: new featurefix: fix bugdocs: only modify the document, such as readme.mdstyle: just modify the format, such as comma, indentation, space, etc. Do not change the code logic. refactor: code refactoring, no new features or bug fixes perf: optimization related, such as improving performance, user experience, etc. test: Test cases, including unit tests and integration tests. chore: Change the build process, or add dependent libraries, tools, etc. revert: version rollback
scope: used to describe the scope of commit impact, such as: views, component, utils, test...
subject: a short description of the purpose of the commit
Body
's specific description of the modification content of this commit, which can be divided into multiple lines . As shown below:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commitFooter has
some remarks, usually BREAKING CHANGE (the current code is not compatible with the previous version) or a link to a fixed bug (close Issue).
After briefly introducing the above specifications, let's talk about commit.template, which is the git submission information template.
git submission information template
If your team has format requirements for submission information, you can create a file on the system and configure git to use it as the default template, which makes it easier to make the submission information follow the format.
Use the following command to configure the submission information template:
git config commit.template [模板文件名] //这个命令只能设置当前分支的提交模板
git config — —global commit.template [模板文件名] //这个命令能设置全局的提交模板，注意global前面是两杠The content of the new .gitmessage.txt (template file) can be as follows:
# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the issue.
# - BREAKING CHANGE
#After reading the above, will you feel that configuration is troublesome like me? It seems that it is not easy to configure a nearly perfect commit specification that suits you and your team. However, the community also provides us with some auxiliary tools to help with the submission. Let's briefly introduce these tools.
commitizen
commitizen is a tool that can interactively create submission information, and can automatically generate qualified commit messages
Install
npm install -g commitizen
and use
commitizen init cz-conventional-changelog --save --save-exact
commit in the project.
You can use git cz when submitting. Then you can generate an automated commit message according to the prompt. 
When using Commitizen, first Use the up and down keys to control the type you want, corresponding to the above mentioned feat, fix, docs, perf, etc., and then let you select the files affected by this submission, and then let you write a short And a detailed submission description, and finally let you judge whether this submission is a BREAKING CHANGE or is related to an open issue. Finally, when viewing the commit history at that time, you will see a commit message like this:
docs(docs): Update the README file
validate-commit-msg
commitizen can guarantee its own local commit message specifications, but it cannot guarantee that teammates are also standardized, so other tools are needed to check whether teammates' submission records are standardized. Use validate-commit-msg to check the commit message specification of teammates
安装
npm install validate-commit-msg husky -D
添加package.json文件配置
"husky": {"hooks": {"commit-msg": "validate-commit-msg"}}
自定义校验格式（可选）
添加一个.vcmrc文件，配置对象如下：
{"types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"],"scope": {"required": false,"allowed": [""],"validate": false,"multiple": false},"warnOnFail": false,"maxSubjectLength": 100,"subjectPattern": ".+","subjectPatternErrorMsg": "subject does not match subject pattern!","helpMessage": "","autoFix": false} npm install -g conventional-changelog-cliconventional-changelog installgenerate CHANGELOG(main.js): add route' to-m'featexample: git commit
Submission
# Generate CHANGELOG.md and overwrite the previous content conventional-changelog -p angular -i CHANGELOG.md -s -r 0# Generate all released Change logconventional-changelog -p angular -i CHANGELOG.md -w -r 0
Note
conventional-changelog -p angular -i CHANGELOG.md -w can only log the contents of CHANGELOG on the command line, and will not generate files. If you want to generate files, you need to use conventional-changelog -p angular -i CHANGELOG.md- s. More config can be viewed using conventional-changelog --help*