This is the 8th day of my participation in the August More text Challenge. For details, see: August More Text Challenge

One, foreword

In daily development, maintaining good code specifications can help improve the quality of the project. Specifying and following the git Commit specification is conducive to improving project management efficiency. Each team has its own specifications and requirements. Based on the universally recognized specifications on the Internet, the editors have summarized the specifications used by their own teams for your reference.

2. Format of submission

After git add, you need to run the git commit command. For example, to add the corresponding description in the, convention, you need to run the following command: git commit -m To commit.

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

Type indicates the category of submission, scope indicates the scope of modification, Subject indicates the title line, and body indicates the content of the body description. A

is a BLANK LINE that does not contain anything

1. Type description

Type is the category of COMMIT. Only the following identifiers are allowed

  • Feat: Add new features
  • Fix: fix the bug
  • Docs: The document has changed
  • Style: Code format changes without changing code logic
  • Refactor: Code refactoring without adding new features or fixing bugs
  • Perf: Optimizations related, such as performance, experience
  • Test: Adds test code
  • Chore: Changing the build process, or adding dependent libraries, associated package upgrades, tools, etc
  • Revert: Roll back to the previous version

2, Scope description [Optional]

Non-mandatory (recommended). Scope specifies the scope of the impact of the commit. It is recommended to specify the functional modules affected by the commit. If your change affects more than one scope, you can use * instead.

3. Subject Description

  • Mandatory, a short description of the commit purpose, in no more than 50 characters.
  • It is recommended to start with a verb, such as: set, modify, add, delete, undo, etc
  • Use the first person present tense, such as change, instead of changed or changes
  • The first letter is lowercase
  • Without a full stop at the end

4. 【 Optional 】

Optional (recommended), which describes the behavioral details of the current modification or the purpose of the modification.

5. Footer description

Non-mandatory, generally used to describe BREAKING CHANGE, generally do not need to fill in the project development, component research and development projects need to fill in. The Footer section is only used in two cases. (1) Incompatible changes If the current code is not compatible 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: upgrade the dependent version, no longer support 12.0.0 or belowCopy the code

If the current commit is for an Issue, you can close the Issue in the Footer section or close multiple issues at once

Closes #234
Copy the code

Iii. Submission method

After you run git commit, go to the Vim editor and add the commit information before the comment in the format specified above.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
#       new file:   source/_posts/011.md
#
# Changes not staged for commit:
#       modified:   package-lock.json
#       modified:   package.json
#       modified:   themes/next (modified content, untracked content)
#
Copy the code

After the input is complete, save the file and run git push command to complete the submission.