I. What is semantic submission information?

The concept of “semantic commit information” comes from ConventionalCommits.org and is known as “compact commit”.

The advantages of regular form submission are:

  • You can create a clear commit history
  • Make it easier to automate standards-based tools: for example, automatically generate CHANGELOG
  • Reduce bugs and improve efficiency
  • More professional

Contractual submissions are written in a fixed pattern, not only to facilitate team collaboration, but also to automate the generation of some documentation later in the project. Common formulas are described below.

The formula

< type >[optional scope]: < description > // Empty line here [optional body] // Empty line here [optional footnote]Copy the code

Description is the format of message used in git commit -m

.

Scope is not required: specifies the scope of the commit,

For example, which layer of the project is generally layered: the data layer, the business logic layer, or the view layer, depending on the project.

A subject is a short description of the purpose of a COMMIT:

  • It usually begins with a verb
  • Lowercase first letter
  • Without a full stop at the end

Type specifies the category of commit. Type is mandatory

Where the type field can be one of the following:

  • Feat: indicates a new feature
  • Fix: Indicates that the commit fixes a bug
  • Docs: The document is modified
  • Style: indicates that the style is changed
  • Refactor: Indicates that the code is refactored
  • Test: Tests are performed
  • Perf: indicates performance optimization
  • A chore: Chore. If you don’t know how to category it, let’s call it 🙂 refers to code or configuration changes in a build process or a chore in an auxiliary tool

Here’s an example:

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
Copy the code

More examples:

Chore: Add Oyster build Script Docs: Explain hat Wobble feat: Add Beta sequence Add Polish language fix: remove broken confirmation message // Submit instructions for fix, including (optional) issue number fix: correct minor typos in code see the issue for details on the typos fixed closes issue #12 refactor: share logic between 4d3d3d3 and flarhgunnstow style: convert tabs to spaces test: ensure Tayne retains clothingCopy the code

Take a look at the commits list in the VUe.js warehouse,

You’ll find that this canonical approach to commit management looks not only professional,

It also helps open source participants understand the meaning of each commit.

See the Commit Message and Change Log writing Guide for more details

Automate Lint Git Commit messages

So the question is coming, if there is a project, from beginning to end all is you a person in maintenance, so you can write all what you want, no one interfere with you, but if it is more than a maintenance project, everyone have their own ideas, even the “end each line of code to add a semicolon” this kind of hard to unified behavior, let alone a submit code?

We need a tool that can verify the format of the submitted information: commitLint

The installation

# Install dependencies
npm i husky lint-staged prettier @commitlint/cli @commitlint/config-conventional -D
Copy the code

configuration

Package. json:

"husky": {
    "hooks": {
      "pre-commit": "npm run lint-staged"."commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}},"lint-staged": {
    "*.js": [
      "npm run prettier"]},Copy the code

Commit-msg “: “commitlint-e HUSKY_GIT_PARAMS” commitlint-e HUSKY_GIT_PARAMS” : commitlint-e HUSKY_GIT_PARAMS

The format is from the configuration file: commitlint.config.js:

module.exports = {
  extends: ["@commitlint/config-conventional"]};Copy the code
  • @commitlint/cli github repo
  • @commitlint/config-conventional

A successful execution is shown in the following figure

3. Automatically generate changelog. md file

If you are developing an external project or tool, it is a good idea to provide a changelog. md file in the repository for users to view the project’s change history, which will help users understand your project better.

The principle of

Quote:

Generate a changelog from git metadata

This tool is a Chagelog file generated based on the commit information of Git commit.

The angular submission specification is currently widely used in the community

How to automate the generation of changelog files instead of manually maintaining them by the project author?

It is recommended to use the NPM package Conventional – Changelog. You can automatically generate a project change history file by running a single command.

The installation

The source code of the project is available on Github, if you are interested, take a look.

# installation
$ npm install -g conventional-changelog-cli
Copy the code

After successful installation, check out the help documentation for this command line tool:

# View help
$ npx conventional-changelog --help
Copy the code

Therefore, we can easily generate the change history by using the following command:

# Generate changelog. md file
$ conventional-changelog -p angular -u -i CHANGELOG.md -s -r 0
Copy the code

What if the order is too long to remember? Put in NPM scripts:

// package.json
scripts: {
    "changelog": "conventional-changelog -p angular -u -i CHANGELOG.md -s -r 0"
}
Copy the code

In the future, you only need to run NPM run changelog on the command line.

There are lots of interesting and useful features to explore, so let me know in the comments if you have any questions.