How should a git commit message be written?

Time:2022-6-18

Since the company hasn’t stipulated a code submission specification since I joined the company, I have been submitting code for a long timecommit messageIt is a simple sentence that explains the content of this code change. Sometimes it will be more concise.

But after a long time, when I need to look back for a submitted record, I will find it difficult to find. First of all, there is no specific classification, such as adding functions, repairing bugs, or updating documents; Secondly, there are somemessageThe writing is not very clear, so I can’t see what the changes were.

Later, I decided that I needed to learn more aboutcommit messageSpecification for the writing of.

Benefits of commit message

  • Of each submitted recordmessageIt can provide more effective information for us to browse quickly;
  • have access togit log --grep <keyword>Filter out somecommit, which is easy to find information quickly;
  • Can be directly fromcommitgenerateChange log

Commit message format

at presentCommit MessageThe most commonly used specifications areSpecifications of angular teamAnd then derivedConventional Commits sepcification

Commit MessageIt consists of three parts:HeaderBodyandFooter。 The format is as follows:

<type>(<scope>): <subject>
< blank line >
<body>
< blank line >
<footer>

Of which,HeaderIs required,BodyandFooterIt can be omitted.

Header

HeaderIt consists of three parts:typescopeandsubject。 amongscopeIs optional.

<type>(<scope>): <subject>

# example
feat($route): add support for the `reloadOnUrl` configuration option

type

typeYes for descriptioncommitThe specific identification is as follows:

  • feat: a new feature(feature);
  • fix: repairbug;
  • docs: modify the document, such asREADME.mdCHANGELOG.mdEtc;
  • style: modify the format of the code without affecting the code operation, such as spaces, formatting codes, complementing semicolons at the end of sentences, etc;
  • refactor: code refactoring, no addition of new functions and code changes for bug repair;
  • perf: optimize code to improve performance;
  • test: add tests or optimize and improve existing tests;
  • build: modify external dependencies that affect the project build file, such asnpmgulpwebpackbroccoliEtc;
  • ci: modify CI configuration files and scripts;
  • chore: modification of other non SRC path files and test files, such as.gitignore.editorconfigEtc;
  • revert: Code fallback;

scope

scopeYes for descriptioncommitThe scope of influence, such as data layer, control layer, view layer, etc., varies according to the project.

If your changes affect more than onescope, you can use*Substitute.

subject

subjectyescommitThe purpose of is a simple description, no more than 50 characters, and the end does not need a period.

Body

BodyPart is about thiscommitCan be divided into multiple lines.

BodyThe section should explain the motivation for the code change and the comparison with the previous behavior.

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 indent

Footer

FooterThis section is mainly used in two cases: incompatible changes and processingIssue

Incompatible changes

If the current code is not compatible with the previous version, thenFooterPartially byBREAKING CHANGE:At the beginning, the following is the 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 relying 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.

Process issue

If currentcommitIs for processing aissue, then you canFooterPartially dimensionedissue

Fixes #234

If you want to close thisissueIf:

Closes #234

Related plug-ins

Commit – quickly write a commit message

https://github.com/commitizen…

We can use third-party plug-insCommitizenTo quickly write ourCommit Message

First, install it globallyCommitizen

npm i -g commitizen

Then, under our project path, run the following command to make it supportAngularofCommit MessageFormat.

commitizen init cz-conventional-changelog --save --save-exact

After the installation, each time we submit the code, we will no longer use itgit commit -mCommand, but usegit czTo perform the operation.

git cz

First selectCommit Type, and then press enter to confirm.

[email protected], [email protected]

? 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, 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)

Then enterscopeInformation for.

What is the scope of this change (e.g. component or file name): (press enter to skip)

Then entersubjectInformation.

Write a short, imperative tense description of the change (max 85 chars):

Following configurationBobyInformation for.

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:

Final configurationFooterInformation.

Describe the breaking changes:

? Does this change affect any open issues? Yes
? Add issue references (e.g. "fix #123", "re #123".):

Commitlint – verify your commit message

https://github.com/marionebl/…

CommitlintCan help us checkCommit Messages, if our submission does not conform to the specification pointed to, it will be rejected directly.

Therefore, we also need to provide it with a verification configuration, which is recommended here@commitlint/config-conventional(in accordance with angular team specifications).

Installation:

npm i -D @commitlint/config-conventional @commitlint/cli

At the same time, you need to create a configuration file under the project directory.commitlintrc.js, write:

module.exports = {
      extends: [
            "@commitlint/config-conventional"
      ],
      rules: {}
};

For more relevant configurations, please refer to the official documentation.

Standard Version – automatically generate changelog

https://github.com/convention…

When ourCommit MessageIf we meet the standard of angular team, we can usestandard-versionSuch tools can automatically generate changelog and even semantic version numbers(Semantic Version)。

Installation:

npm i -S standard-version

package.jsonto configure:

"scirpt": {
    "release": "standard-version"
}