Since the company has not stipulated a code submission standard so far, the commit message of my code submission has always been a simple sentence explaining the code changes, sometimes more concise.
However, after a long time, when I need to look back for a certain submission record, I will find it is not easy to find. Firstly, there is no specific classification, such as whether to add features, fix bugs, or update documents, etc. Secondly, some messages are not very clear, and it is not easy to see what the change is.
I decided that I needed to relearn the specification for writing commit messages.
Benefits of a Commit Message
- For each record submitted
message
Can provide more effective information, convenient for us to browse quickly; - You can use
git log --grep <keyword>
Filter out certaincommit
, easy to find information quickly; - You can get it directly from
commit
generateChange log
.
A Commit Message format
Currently, the Commit Message specification is mainly used by the Angular team, which has evolved into Conventional Commits sepcification.
The Commit Message consists of three parts: Header, Body, and Footer. The format is as follows:
<type>(<scope>): <subject> < blank line > <body> < blank line > <footer>Copy the code
Header is mandatory, Body and Footer can be omitted.
Header
The Header contains three parts: Type, Scope, and Subject. Scope is optional.
<type>(<scope>): <subject>
# example
feat($route): add support for the `reloadOnUrl` configuration option
Copy the code
type
Type is the type used to specify the commit. The specific identifier is as follows:
feat
: a new feature (feature
);fix
Repair:bug
;docs
: Modify the document, for exampleREADME.md
,CHANGELOG.md
And so on;- Style: Modify the format of the code without affecting the operation of the code, such as Spaces, formatting code, complete the semicolon at the end of the sentence, etc.
- Refactor: code refactoring, code changes without new features and bug fixes;
- Perf: Optimize code to improve performance
- Test: Add tests or improve existing tests;
build
: Changes that affect project build files or external dependencies, such asnpm
,gulp
,webpack
,broccoli
And so on;- Ci: Modify ci configuration files and scripts.
chore
: Changes to other non-src path files and test files, such as.gitignore
,.editorconfig
And so on;- Revert: code rollback;
scope
Scope is used to specify the scope of the commit, such as the data layer, control layer, view layer, and so on, depending on the project.
If your changes affect more than one scope, use * instead.
subject
Subject is a simple description of the purpose of the commit, no more than 50 characters long, and does not require a period at the end.
Body
The Body section is a detailed description of the commit, broken into multiple lines.
The Body section should explain the motivation for the code change and how it compares to previous actions.
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. Further paragraphs come after blank lines. - Bullet points are okay, too - Use a hanging indentCopy the code
Footer
The Footer section is mainly used in two cases: incompatible changes and processing issues.
Incompatible variation
If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE:, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method.
BREAKING CHANGE: Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned in component Constructors. In Angular 1.5+ the place to put the initialization logic to adopt on bindings being present is the controller $onInit method. To migrate follow the example below: Before: ```js angular.module('myApp', []) .component('myComponent', { bindings: {value: '<'}, controller: function() { this.doubleValue = this.value * 2; }}); ``` After: ```js angular.module('myApp', []) .component('myComponent', { bindings: {value: '<'}, controller: function() { this.$onInit = function() { this.doubleValue = this.value * 2; }; }}); this.doubleValue = this.value * 2; }; }}); ``` Don't do this if you're writing a library, though, as you shouldn't change global configuration then.Copy the code
To deal with Issue
If the current COMMIT is dealing with an issue, you can mark the issue being processed in the Footer section.
Fixes #234
Copy the code
If you want to close this issue:
Closes #234
Copy the code
Related to the plug-in
Commitizen – Quickly write a Commit Message
Github.com/commitizen/…
We can use a third-party plug-in, Commitizen, to quickly write our Commit messages.
Start by installing Commitizen globally.
npm i -g commitizen
Copy the code
Then, in our project path, run the following command to support Angular’s Commit Message format.
commitizen init cz-conventional-changelog --save --save-exact
Copy the code
Once the installation is complete, instead of using git commit -m, we will use Git Cz every time we commit code.
git cz
Copy the code
Select Commit Type and press Enter to confirm.
[email protected], [email protected]? Research the type of change that you're right (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, for matting, missing semi-colons, etc) refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance (Move up and down to reveal more choices)Copy the code
Then enter the scope information.
What is the scope of this change (e.g. component or file name): (press enter to skip)
Copy the code
Then enter the Subject information.
Write a short, imperative tense description of the change (max 85 chars):
Copy the code
Then configure the Boby information.
Provide a longer description of the change: (press enter to skip):
? Are there any breaking changes? Yes
? A BREAKING CHANGE commit requires a body. Please enter a longer description of
the commit itself:
Copy the code
Finally, configure Footer information.
Describe the breaking changes: ? Does this change affect any open issues? Yes ? Add issue references (e.g. "fix #123", "re #123".) :Copy the code
Commitlint – Validates your Commit Message
Github.com/marionebl/c…
Commitlint can help us check Commit Messages and reject them if they don’t conform to the pointing specification.
Therefore, we also need to provide it with a verified configuration, which is recommended for @commitlint/ config-Conventional (compliant with the Angular team specification).
Installation:
npm i -D @commitlint/config-conventional @commitlint/cli
Copy the code
You need to create a configuration file in the project directory. Commitlintrc.js, and write: commitlintrc.js
module.exports = {
extends: [
"@commitlint/config-conventional"].rules: {}};Copy the code
Check out the official documentation for more configurations.
Standard Version – Automatically generates CHANGELOG
Github.com/conventiona…
When our Commit Message conforms to the Angular team’s specifications, we can use tools like standard-version to automatically generate CHANGELOG, or even Semantic versions.
Installation:
npm i -S standard-version
Copy the code
Package. Json configuration:
"scirpt": {
"release": "standard-version"
}
Copy the code