A good commit habit will definitely pay off in future code maintenance.

For example, one day a feature you wrote went wrong, and you found out where the code was changed, only to find that a colleague had changed a line of code. You were completely confused because he did not write a comment, and he only wrote a random sentence in the commit record, and had no idea why he changed it like that. You want to change back, but you are afraid of affecting other places. If you do not change back, you can only think of ways to change your original logic.

A good submission can completely avoid this situation, as can the Changelog information, which is a good way to go back to what has been done over a period of time, understand the overall progress of the project, and help code review.

Git Commit specification

The specification uses Angular Git Commit Guidelines

A Commit Message format

Each Commit message contains three parts: header, body, and footer.

The header is special and contains three parts: Type, Scope, and Subject

The specific format is as follows:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code

Each line cannot exceed 50 Characters in length.

Revert

If the commit reverts a previous commit, it should begin with revert:, followed by the header

of the reverted commit.

In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit

being reverted.

A commit with this format is automatically created by the [git revert][git-revert] command.

Type (required)

The commit type must be one of the following:

  • Feat: A new feature
  • Fix: A bug fix
  • Docs: Only modified documents, such as README, CHANGELOG, CONTRIBUTE, etc
  • Style: Changes that do not affect code logic, such as Spaces, formatting indentation, removing semicolons, and so on
  • Refactor: Code refactoring
  • Perf: Changes to improve performance
  • Test: Adds or modifies tests
  • Chore: Change the build process, or add helper tools, dependency libraries, etc

Scope (optional)

Scope is used to specify the scope of commit impact

You can use * when the change affects more than a single scope.

Subject (must)

Subject is a short description of this change:

* Begin with a verb and use the first person present tense, such as "change" rather than "changed" or "changes" * Lowercase * and end without a periodCopy the code

Body (optional)

A detailed explanation of the purpose and motivation of the revision:

* What features have been added? * Why are you doing this? * How did you solve this problem? * Are there any side effects or other risks?Copy the code

Footer (optional)

Breaking Changes are disruptive Changes, such as incompatible Changes.

Watches can also be used to stop issues, watches #123, #245,

You don’t really need this in normal business projects.

Commit tool — Commitizen

Commitizen CLI:

npm install commitizen -g
Copy the code

Then, run the following command in your project (required for every new project) :

commitizen init cz-conventional-changelog --save-dev --save-exact
Copy the code

Git cz instead of git commit

For details, see cZ – CLI.

Commit template

For normal project development, using the Commitizen CLI for every commit is still time-consuming, and it’s easy to make a mistake by pressing it fast, so it’s better to use the COMMIT template for daily development.

Method one:

Right-click and open the TortoiseGit Settings screen

Adding a COMMIT Template

Note: The path should be split by two backslashes or slashes, the template needs to create a TXT file and write.

Commit with TortoiseGit:

Method 2:

Using Native Git

Git config -- global commit.Copy the code

Note: this method has not been used before, if you encounter problems, please baidu yourself

Automatically generate the Change log

As long as the Commit Message complies with the Angular specification, we can use tools like standard-version to automatically generate CHANGELOG files.

Standard-changelog is based on Conventional Changelog. The usage is as follows:

First install to the development environment

npm install --save standard-changelog
Copy the code

Then configure package.json

"scripts": {
    "release-f": "standard-version -f",
    "release-major": "standard-version -r major",
    "release-minor": "standard-version -r minor",
    "release-patch": "standard-version -r patch"
}

CLI command options:

-i, --infile Read the CHANGELOG from this file -f, --first-release Generate the CHANGELOG for the first time -o, --outfile Write the CHANGELOG to this file. If unspecified (default: CHANGELOG.md) -s, --same-file Overwrite the infile (default: true) -p, --preset Name of the preset you want to use (default: angular) -k, --pkg A filepath of where your package.json is located -a, --append Should the generated block be appended -r, - release - count How many releases to be generated from the latest (like NPM version < major | minor | patch | 1.1.0 >) [string] - v, --verbose Verbose output -c, --context A filepath of a json that is used to define template variables -l, -- Lerna-package Generate a changelog for a specific Lerna package (:[email protected]) --commit-path Generate a changelog scoped to a specific directoryCopy the code

Major: Usually represents a major release update; Minor: indicates that functions are added. Patch: indicates bug fixes major: 1.0.0 -> 2.0.0, minor: 1.0.0 -> 1.1.0, patch: 1.0.0 -> 1.0.1

Reference article:

  1. commit-message
  2. Guide to writing Commit Message and Change log