What is it?
The Conventional Commits is a specification that seeks to improve the commit messages. It can be considered as a standard format when writing commit messages.
Why use it?
Because:
- creates explicit commit history (it describes features, fixes, breaking changes, etc) in order to better communicate the nature of changes to teammates/public/stakeholders and making it easier for contributors by allowing them to explorer a more structured commit history
- can be processed by automated tools to produce documentation such as release notes or to trigger build and publish processes
Examples
- fix: patches a bug in the codebase
- feat: introduces a new feature to the codebase
- BREAKING CHANGE: introduces a breaking change. It can be a part of commit message of any type
- refactor: improves the existing code base
- perf: improves the performance of algorithms or general execution time of the product, but does not fundamentally change an existing feature.
- build: alters the build system or external dependencies of the product (adding, removing, or upgrading dependencies).
- chore: includes a technical or preventative maintenance task but it is not tied to any specific feature
- ci: makes changes to continuous integration or continuous delivery scripts or configuration files.
- docs: makes changes to the documentation
- style: makes changes to the code style (semicolon, indentation…)
- test: add tests to an existing feature