mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2025-08-22 22:08:35 +00:00
feat: Add explicit differences between body and footer in specs
Fixes: #37
This commit is contained in:
parent
ac7b0d93d5
commit
55dfd98bb2
20
index.md
20
index.md
@ -89,24 +89,24 @@ debug issues across project boundaries.
|
|||||||
|
|
||||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||||
|
|
||||||
1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
|
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
|
||||||
followed by a colon and a space.
|
followed by a colon and a space.
|
||||||
2. the type `feat` MUST be used when a commit adds a new feature to your application
|
2. The type `feat` MUST be used when a commit adds a new feature to your application
|
||||||
or library.
|
or library.
|
||||||
3. the type `fix` MUST be used when a commit represents a bug fix for your application.
|
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||||
4. an optional scope MAY be provided after a type. A scope is a phrase describing
|
4. An optional scope MAY be provided after a type. A scope is a phrase describing
|
||||||
a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||||
5. A description MUST immediately follow the type/scope prefix.
|
5. A description MUST immediately follow the type/scope prefix.
|
||||||
The description is a short description of the pull request, e.g.,
|
The description is a short description of the code changes, e.g.,
|
||||||
_fix: array parsing issue when multiple spaces were contained in string._
|
_fix: array parsing issue when multiple spaces were contained in string._
|
||||||
6. A longer commit body MAY be provided after the short description. The body MUST
|
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||||
begin one blank line after the description.
|
7. A footer MAY be provided one blank line after the body (or after the description if body is missing).
|
||||||
7. A footer MAY be provided one blank line after the body. The footer SHOULD contain
|
The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g.,`Fixes #13`).
|
||||||
additional meta-information about the pull-request (such as the issues it fixes, e.g., `fixes #13, #5`).
|
|
||||||
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||||
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||||
has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||||
10. types other than `feat` and `fix` MAY be used in your commit messages.
|
10. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information.
|
||||||
|
11. Types other than `feat` and `fix` MAY be used in your commit messages.
|
||||||
|
|
||||||
## Why Use Conventional Commits
|
## Why Use Conventional Commits
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user