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 submittedmessageCan provide more effective information, convenient for us to browse quickly;
  • You can usegit log --grep <keyword>Filter out certaincommit, easy to find information quickly;
  • You can get it directly fromcommitgenerateChange 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);
  • fixRepair:bug;
  • docs: Modify the document, for exampleREADME.md,CHANGELOG.mdAnd 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,broccoliAnd so on;
  • Ci: Modify ci configuration files and scripts.
  • chore: Changes to other non-src path files and test files, such as.gitignore,.editorconfigAnd 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