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
<body>
// One blank line
<footer>
Among them, Header Is required, Body and Footer Can be omitted
Example:
PS D:\git\pythonPractice> git log
commit 58a7a966acb9aa2fffc0e02c9ce3be64b8949991 (HEAD -> master)
Author: Zhiwei Tian <hebeitianzhiwei@outlook.com>
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.
- 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
- Run the command in the project directory
commitizen init cz-conventional-changelog --save --save-exact
- 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
- 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
git-cz
Reference link:
Ruan Yifeng Blog
Jartto's blog
cz-cli
Author: TinChiWay
Link: https://www.jianshu.com/p/36d970a2b4da
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.