Git commit code specification

I. Why do we need to develop submission specifications?

In collaborative development, everyone writes a Commit message when they commit code.

Everyone has their own writing style, and if you look at our group’s git log, you can see that there are many different types of writing styles, which are very difficult to read and maintain.

In general, big companies have their own set of commit specifications, especially in large open source projects, where the Commit Message is very consistent.

Therefore, we need to develop a unified standard, promote the team to form a consistent style of code submission, better improve work efficiency, and become an aspiring engineer.

What are the common Git commit specifications in the industry?

1. commitizen

AngularJS’s GitHub submission record has been recognized by many in the industry and is increasingly being cited.

Format:

type(scope) : subject

(1) Type (Must) : Commit. Only the following flags are allowed:

  • FEAT: New features
  • Fix the bug
  • Docs: Document changes
  • Style: Code format change
  • Refactor: Refactor an existing feature
  • Perf: Performance optimization
  • Test: Add a test
  • Build: Changed build tools such as Grunt to NPM
  • Revert: Undo the last commit
  • Chore: Changes to the build process or assistive tools

(2) SCOPE (optional) : Indicates the scope of impact of the COMMIT, such as the data layer, control layer, view layer, etc., depending on the project.

(3) Subject (Must) : A short description of the Commit, no more than 50 characters. CommiTizen is a tool for writing a qualified Commit Message, following the Angular Commit specification.

Installation:

Install CommiTizen globally

npm install -g commitizen

Go to the project folder and run the following command:

commitizen init cz-conventional-changelog --save --save-exact

Use:

Replace Git Commit with the git cz command (use git add first), which will present the following options:

(1) Select Type

(2) Fill in SCOPE (Optional)

? What is the scope of this change (e.g. component or file name)? (press enter to skip)
core

(3) Fill in Subject

? Write a short, imperative tense description of the change:
set a to b

When done, run the git log command and look at the commit message we just committed, as follows:

fix(core): set a to b

Advantages:

  • Compliance with industry standards (many projects use AngularJS Commit specification)
  • Submission process is more standardized (using Commititizens specification tool, unified style)
  • Generate a consistent commit log (type(scope):subject)

Disadvantages:

  • CommiTizen Toolkit needs to be installed to make the project bigger and heavier (suitable for large open source projects)
  • The submission process is highly constrained
  • There are certain learning costs

2. Set the Git Commit template

Here are the steps:

(1) Establish template files

Create a.git_template file in your project. The contents can be customized:

type:
scope:
subject:

(2) Set the template

Run the following command:

Git config commit. Template.git_template -- git config commit. Template.git_template // global setting -->

(3) Submit the code

Use Git Commit to fill in the template and then git push to the remote end

Advantages:

  • Rules are configurable and more free
  • Simple configuration (just add a configuration file)

Disadvantages:

  • Convenience is poor, each time you have to use the Vim editor to fill in the template
  • Error prone, there is no reliable way to check

Create a Git Commit specification that suits us

Neither of the two industry-wide norms mentioned in Chapter 2 is entirely appropriate for us.

The first method is suitable for large open source projects, and it will be troublesome for us to follow the same method, but we can use the submission format of type(scope): subject, which is also synchronized with large factories; The second way, which is free but less cumbersome, is to configure the template. Therefore, we only imitate the submission format of Type (Scope): Subject, without using tools or templates for verification, and it is up to everyone to consciously follow them.

format

type: description

1. Type type

Type is the Commit category, and only the following types of identification are allowed:

  • Fix: fix the bug
  • Add: new features
  • Update: update
  • Style: Code format change
  • Test: Add test code
  • Revert: Undo the last commit
  • Build: Change to the build tool or process, e.g. Gulp to Webpack, Webpack upgrade, etc

2. description

Description is a short description of the submission.

No more than 50 characters.

It is recommended to start with a verb, such as: Set, Modify, Add, Remove, Undo, etc

Finally, since made the rule, everybody observes rise ~~~~