Normalize the role of the Commit message

  • Provide more historical information
  • You can filter submissions
  • You can generate Change logs directly from commit

Here’s a small commit message

This is the generated CHANGELOG

Now how do I write a canonical Commit Message

Git Commit Message format

The prevailing specification is the Angular team’s specification, which derives from 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

Each submit message consists of a header, body, and footer, where the body and footer can be omitted

Header

The header is a single line with three fields: Type (required), scope (optional), and subject (required)

Type Indicates the type of commit

  • Feat a new feature
  • Error fix
  • Docs document
  • Style does not affect changes in code meaning (Spaces, formatting, missing semicolons, etc.)
  • Refactor code changes neither fix bugs nor add functionality
  • Perf: Code changes that improve performance
  • Test Adds missing or corrects existing tests
  • Chore changes to the build process or helper tools and libraries such as document generation

The scope ranges

A scope can be anything that specifies where the change is committed and can be * used when the change affects more than one scope

The subject topic

The brief description of the commit can contain no more than 50 characters. You are advised to commit the commit in English.

  • Use imperative, use “change” not “changed” not “changes”
  • Don’t capitalize the first letter
  • There’s no point at the end.

Body body

The body section is a detailed description of the commit, which can be broken into multiple lines, such as how it is different from before the commit.

Footer footer

compatibility

All major changes must be mentioned as a CHANGE block in the footer, which should begin with the word “BREAKING CHANGE” : a line or two empty. The rest of the commit message is then a description of the changes, reasons, and migration instructions.

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.
    
    To migrate the code follow the example below:
    
    Before:
    
    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }
    
    After:
    
    scope: {
      myAttr: The '@',
      myBind: The '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor } The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Copy the code

issue

Watches closing issus should be listed in a separate line in the footer prefixed with the keyword “watches” as follows:

Closes # 234/ / multiple Closes# 123, # 245, # 992
Copy the code

For more information

Take a chestnut

Commitizen/Cz – CLI automatically generates a standard Commit Message, which I won’t go into here

feat: write log message into file

Put log message into appoint dir, it will create the dir if not exist

Copy the code
refactor(package.json): update nodejs version and license

The version was 1.0.0, the license was ISC before update, and now, the version is 0.0.1, license is MIT

Copy the code

More chestnuts