Why normalize Git commit information

Every time Git commits code, write a Commit message, otherwise Commit is not allowed. However, in general, the Commit message should be clear and state the purpose of the commit. But everyone has a different style of doing things, and it’s possible to submit instructions that are confusing. Take an extreme example, see the following figure:

Therefore, it is better to have a discipline that reduces the cost of communication between teams, makes the commit log easier to understand, and easier for people outside the team to understand!

Normalize the role of Git commit information

  • Provides more historical information for quick browsing.
  • Certain commits, such as document changes, can be filtered to make it easy to find information quickly
  • You can generate Change logs directly from commit.
  • Readable and clear, you can understand what the current COMMIT does without looking deeply into the code.
  • Preparing for Code Reviewing
  • Easy to track engineering history
  • Make other developers feel grateful when running Git Blame
  • Improve the overall quality of the project, improve personal engineering quality

Git commit Normalizes the use of git Commitizen

The installation

Install Commitizen globally

npm install -g commitizen
Copy the code

For use in projects

  1. Initialize commitizen in your project, switch to the root directory of your project, and run the following command:
commitizen init cz-conventional-changelog --save --save-exact
Copy the code
  1. This command is used when submitting code
Git add. Git cz // No longer need to execute git commitCopy the code

A message is displayed. Enter the commit information step by step as prompted. The formatted COMMIT information is displayed

Git commitizen formatting structure

For each Commit, the Commit message consists of three parts: header, body, and footer.

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

The header is required, and the body and footer can be omitted. No line should be longer than 72 characters (or 100 characters) in any section. This is to avoid the aesthetics of wrapping.

  • Header

    The Header section is a single line with three fields: Type (type, required), scope (image scope, optional), and Subject (shorthand, required).

    • type

      Only the following 11 identifiers are allowed to describe the commit category.

      • Function of feat:
      • Fix: Fixes bugs
      • Docs: Changes only the content related to the document
      • Style: Changes that do not affect the meaning of the code, such as removing Spaces, changing indentation, adding and deleting semicolons
      • Refactor: Code refactoring
      • Perf: Changes to improve performance
      • Test: Adds tests or modifies existing tests
      • Build: Changes to build tools or external dependencies, such as Webpack, NPM
      • Ci: Changes related to CI (Continuous Integration Services)
      • Chore: Other miscellaneous modifications, such as changes to the build process or ancillary tools
      • Git Revert: Do git Revert to print messages

    • Scope

      This is an optional field that describes the scope of the impact of this Commit.

    • Subject

      This is a brief description of the change, with a brief overview and detailed information provided later in the Body. And it’s best to follow these two rules:

      • Start with a verb and use the present first-person tense such as “change” rather than “changed” or “changes”
      • Ending without a period

  • body

    A detailed description of this change

  • footer

    The footnote section, which is generally only used in the following two cases:

    • Incompatible variation

      If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method.

      BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:

Before:

scope: {
	myAttr: 'attribute',
}

After:

scope: {
	myAttr: '@',
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Copy the code

    • Close the Issue

      If the current commit is for an issue, you can close the issue in the Footer section.

      Closes #234
Copy the code