Git Conventional Commits
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
- Automatically generating CHANGELOGs.
- Automatically determining a semantic version bump (based on the types of commits landed).
- Communicating the nature of changes to teammates, the public, and other stakeholders.
- Triggering build and publish processes.
- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
The type must use lowercase, cannot empty, followed by the OPTIONAL scope, OPTIONAL
!, and REQUIRED terminal colon and space.
There are all available commit types:
A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis.
The description is a short summary of the code changes, cannot be empty, and does not end with a period.
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.
A commit body is free-form and MAY consist of any number of newline separated paragraphs.
One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a
<space># separator, followed by a string value.
A footer’s token MUST use
- in place of whitespace characters, a only exception is made for
A footer’s value MAY contain spaces and newlines.
Some commit types may affect SemVer changes:
- fix means patches a bug, this correlates with
PATCHin Semantic Versioning.
- feat means introduces a new feature, this correlates with
MINORin Semantic Versioning.
- BREAKING CHANGE is in the footer, or appends a
!after the type/scope, this correlates with
MAJORin Semantic Versioning.
Release Please Action will automatically create release pr includes generated CHANGELOG. When PR is merged, it will create a release, and you can run CI/CD and upload files to the release.
- "Conventional Commits". Retrieved 28 June 2022. ↩
- "gitmoji". Archived from the original on 28 June 2022. Retrieved 28 June 2022. ↩
- "Semantic Versioning". Archived from the original on 28 June 2022. Retrieved 28 June 2022. ↩
- "Release Please Action". Archived from the original on 28 June 2022. Retrieved 28 June 2022. ↩