An easy set of rules for creating an explicit commit history, by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows:
<type>[optional scope]: <description>
feat: add new feature
chore(prettier): change tabs to spaces- build: Build related changes (eg: npm related/ adding external dependencies)
- chore: A code change that external user won’t see (eg: change to .gitignore file or .prettierrc file)
- feat: A new feature
- fix: A bug fix
- docs: Documentation related changes
- refactor: A code that neither fix bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name)
- perf: A code that improves performance
- style: A code that is related to styling
- test: Adding new test or making changes to existing test
A commit that has a footer
BREAKING CHANGE:, or appends a!after the type/scope, introduces a breaking API change (correlating withMAJORin Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
feat(api)!: rename `getUsers` to `getUsersList`