Code submission specification

1. fix: type by fix The submission of indicates that a... Has been fixed in the code base bug（ This and the semantic version of PATCH Corresponding ）.
2. feat: type by feat The submission of represents a new feature in the code base （ This and the semantic version of MINOR Corresponding ）.
3. BREAKING CHANGE: At the beginning of the optional body or footnote, there is BREAKING CHANGE: Submission of , Indicates that disruptive changes have been introduced （ This and the semantic version of MAJOR Corresponding ）. Disruptive changes can be arbitrary type Part of the submission . about fix:、feat: and chore:, And more type for , It's all valid .
4. Others in fix: and feat: Other submissions type They all support , for example Angular Appointment Recommended in docs:、style:、refactor:、perf:、test:、chore:, However, these labels are not mandatory in the agreed submission specification .

Other label meanings ：

docs： file （documentation）
style：  Format （ Changes that do not affect code operation ）
refactor： restructure （ It's not new , It's not a revision bug Code changes ）
test： Add tests 
chore： Changes in the build process or AIDS 

Agreed submission specifications

Keywords in this document “ must ”、“ prohibit ”、“ need ”、“ Should ”、“ It shouldn't be ”、“ should ”、“ Should not be ”、“ recommend ”、“ Sure ” and “ Optional ” Should be in accordance with the RFC 2119 Description and explanation of .

1. Each submission must use the type field prefix , This consists of a shape such as feat or fix The nouns of , Followed by a colon and a space .
2. When a submission implements a new feature for an application or class library , You have to use feat type .
3. When a submission is fixed for an application bug when , You have to use fix type .
4. Optional scope fields can be provided after the type . A scope is a phrase that describes a part of the code base , Enclosed in parentheses , Form like fix(parser): etc. .
5. The description field must immediately follow the type or scope prefix . Description refers to a short description of the code changes , Form like fix: array parsing issue when multiple spaces were contained in string.
6. After a brief description , You can write longer submission text , Provide additional context information for code changes . The body must start with a blank line at the end of the description field .
7. After a blank line at the end of the body , You can write footnotes （ If the text is missing , It can be written after the description ）. Footnotes should include additional... For code changes issue Quote information （ For example, it fixes issue, similar Fixes #13 etc. ）.
8. Disruptive changes must be shown in the body of the submission or in footnotes . A destructive change must contain capitalized text BREAKING CHANGE, Followed by a colon and a space .
9. stay BREAKING CHANGE: A description must then be provided , To describe right API Changes . for example BREAKING CHANGE: environment variables now take precedence over config files.
10. Footnotes must contain only BREAKING CHANGE、 External links 、issue References and other metadata information .
11. In the submission instructions , have access to feat and fix Other types .

Why use contractual submission

1. Automatic generation CHANGELOG.
2. Based on the type of submission , Automatically determine semantic version changes .
3. To colleagues 、 The public and other stakeholders communicate the nature of the change .
4. Trigger the build and deploy process .
5. Make it easier for people to explore structured submission history , Reduce the difficulty of contributing to the project .