Git commit log basic specification
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The format is explained as follows:
● type represents the type of a submission, such as fixing a bug or adding a new feature. All type types are as follows:
● feat: add feature
● fix: fix bugs
● docs: only modify documents, such as README, CHANGELOG, CONTRIBUTE, etc.
● style: only modify spaces, format indentation, etc., Do not change the code logic
● refactor: code refactoring, without adding new functions or fixing bugs
● perf: related to optimization, such as improving performance and experience
● test: test cases, including unit testing, integration testing, etc.
● chore: changing the build process, or Add dependent libraries, tools, etc.
revert: roll back to the previous version
Title line: within 50 characters, describe the main changes # # Main content: more detailed description text, it is recommended to be within 72 characters. Information that needs to be described includes:
- Why is this change necessary? It may be used to fix a bug, add a feature, improve performance, reliability, stability, etc.
- How did he solve the problem? Describe the steps to solve the problem in detail
- Are there any side effects, risks?
- Tail: If necessary, you can add a link to the issue address or other documents, or close an issue. copy code
format requirement:
Git branch and version release specification
● Basic principle: the master is a protected branch, and code modification and submission are not directly performed on the master.
● When developing daily needs or projects, check out a feature branch from the master branch for development or a bugfix branch for bug fixing. After the function test is completed and the project is released and launched, merge the feature branch into the main master and tag it for release, and finally delete the development branch branch. Branch naming convention:
○ Branch version naming rules: branch type branch release time branch function. For example: feature_20170401_fairy_flower
○ Branch types include: feature, bugfix, refactor three types, that is, new function development, bug repair and code reconstruction ○
Use the year, month, and day to name the time, and fill in 0 if it is less than 2 digits
○ Use snake case to name the branch function method, that is, underscore naming.
● Tag includes a 3-digit version, prefixed with v. Such as v1.2.31. Tag naming conventions:
○ The second version number is used for new function development, and the third version number is used for bug fixes.
○ If the core base library or Node middle price can be released in a large version, please use the grayscale version number and add a suffix after the version. Separate them with dashes. Alpha or beta is followed by the number of times, that is, the number of alphas:
■ v2.0.0-alpha-1
■ v2.0.0-belta-1
● Changelog documents need to be generated before the official release of the version, and then released online.