Note: If you like our article don’t forget to click to pay attention to Ali Nanjing technology special issue you ~ this article is reprinted from Ali Nanjing technology special issue – Zhihu, welcome Daniel niu niu to post Ali Nanjing front-end/back-end development and other positions, see Ali Nanjing invites front-end partners to join ~.

Commit message is the daily operation of development. Writing good logs not only helps others review, but also can effectively output CHANGELOG. It is very important for project management, but it is often ignored in practical work. I hope this article can help you to pay attention to and standardize the writing of commit Message.

The cause of

How to write a Git Commit log? It was interesting to see a variety of submission styles: emoji, Tang poetry, random generation. There is no right or wrong style, as long as it reflects the changes made by the COMMIT.

But what impressed me most was @Lihuaqiao’s answer:

Such things, of course, need tools to be able to write specification, format, and support subsequent analysis. The current suggestion is, Use the commitizen/ cz-CLI + Commitizen/CZ-conventional – Changelog + Conventional – Changelog /standard-version tool to release the information and version in one step. Even more aggressive, it is possible to add marionebl/ CommitLint to continuous integration to check commit compliance.

In this article, I’ll show you how to ensure the specification and formatting of a project’s Commit message.

A Commit Message format

The most commonly used specification is the Angular team’s specification, which in turn resulted in Conventional Commits. Many tools are based on this specification, which has the following message format:

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

The final result of the vim interface filled out by the git commit command should look like this structure, roughly divided into three parts (separated by a blank line):

  • Title line: Mandatory, describing the major changes and their contents
  • Topic content: Describe why the changes were made, what changes were made, the thinking behind the development, etc
  • Footer note: Put Breaking Changes or Closed Issues

They are respectively composed of the following parts:

  • Type: Indicates the type of COMMIT
  • Feat: new features
  • Fix: Fix the problem
  • Refactor: Code refactoring
  • Docs: Modify the document
  • Style: Code format modification, note not CSS modification
  • Test: Test case modification
  • Chore: Other modifications such as build process, dependency management.
  • Scope: The scope of the commit effect, such as route, component, utils, build…
  • > > < span style = “style =” style = “style =” style = “style =” style = “style =” style = “style =” style =
  • Body: Commit Specific modification, can be divided into several lines, recommended to conform to 50/72 formatting
  • Footer: Some notes, usually links to BREAKING changes or fixed bugs.

Such a conforming commit message is just like an email.

Git commit template

If you’re just a personal project, or you want to try this out, you can set up a Commit template for Git and bring it to vim every time you commit, reminding yourself:

Modify ~/.gitconfig and add:

[commit]
template = ~/.gitmessage
Copy the code

A new ~/.gitMessage can be created as follows:

# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer: 
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#
Copy the code

Commitizen: Replace your Git Commit

Our goal is still tool generation and constraint, so let’s get started.

Commitizen /cz-cli, we need to use the git cz command provided by it to replace our git commit command, help us to generate the commit message conforming to the specification.

In addition, we need to specify a Adapter for Commitizen such as Cz-Conventional changelog (a preset conforming to the Angular team specification). Make commItizen help us generate the Commit message according to the specification we specify.

Global installation

npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
Copy the code

In global mode, the ~/. CZRC configuration file is required to specify Adapter for CommItizen.

Project level installation

npm install -D commitizen cz-conventional-changelog
Copy the code

Package. json configuration:

"script": {... ."commit": "git-cz",},"config": {
    "commitizen": {
      "path": "node_modules/cz-conventional-changelog"}}Copy the code

If commitizen has been installed globally, you can perform git cz or NPM Run commit in your project.

The effect is as follows:

Custom Adapter

If we are not used to the Angular specification, we can specify a set of specifications that conform to our own team by specifying Adapter cz-Customizable.

Global or project level installation:

npm i -g cz-customizable
or
npm i -D cz-customizable
Copy the code

Change the config in.czrc or package.json to:

{ "path": "cz-customizable" }
or
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"}}Copy the code

Also create a.cz-config.js file in the ~/ or project directory and maintain the format you want: for example, my configuration file: leohxj/.cz-config

The effect is as follows:

Commitlint: Commitlint verifies your message

Commitlint: can help us to lint commit messages, if we do not conform to the point to the specification of the submitted, direct refused to commit, ferocious.

Again, it requires a validation configuration. @commitLint/config-Conventional is recommended.

Installation:

npm i -D @commitlint/config-conventional @commitlint/cli
Copy the code

At the same time, create configuration file. Commitlintrc. js in the project directory and write:

module.exports = {
  extends: [
    ' '@commitlint/config-conventional' '
  ],
  rules: {
  }
};
Copy the code

Lint for custom Adapter

If, like me, you are using a custom Commitizen Adapter, you need to:

npm i -D commitlint-config-cz @commitlint/cli
Copy the code

Commitlintrc.js:

module.exports = {
  extends: [
    'cz'
  ],
  rules: {
  }
};
Copy the code

Combining with the Husky

The best way to verify a Commit message is with git hooks, so you need to work with Husky.

npm i husky@next
Copy the code

In package.json add:

"husky": {
    "hooks": {... ."commit-msg": "commitlint -e $GIT_PARAMS"}},Copy the code

The effect is as follows:

Standard-version: automatically generates a CHANGELOG

With the help of these tools, our project commit message should be consistent with that of the Angular team, which makes it easier for us to automatically generate CHANGELOG with a tool like standard-version. Even Semantic Version numbers.

Installation and use:

npm i -S standard-version
Copy the code

Package. Json configuration:

"scirpt": {... ."release": "standard-version"
}
Copy the code

PS: Standard-version has a lot of other features, here is not much involved, interested students to try their own.

The last

The discipline of commit message is important, but whether you need to impose restrictions like this article, each team and individual has their own ideas, but personally think: good habits, benefit for life.