The reasons for these conventions:
- automatic generating of the changelog
- explicit commit history
- simple navigation through git history
- easier to write automated tools on top of commit history
Commit message format:
<type>: <description>
[optional body]
[optional footer(s)]The commit contains the following structural elements, to communicate intent to the consumers of your library:
- fix: a commit of the type
fixpatches a bug in your codebase - feat: a commit of the type
featintroduces a new feature to the codebase - BREAKING CHANGE: a commit that has a footer
BREAKING CHANGE:, or appends a!after the type/scope, introduces a breaking API change. A BREAKING CHANGE can be part of commits of any type. - other types are build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and revert:.
Types
- fix: Bug fix for the user, not a fix to a build script
- feat: New feature for the user, not a new feature for build script
- chore: Changes that do not impact the user (scripts, related to dev tool)
- build: Changes that affect the build system or external dependencies
- ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests or correcting existing tests
- revert: If the commit reverts a previous commit, it should begin with
revert:, followed by the header of the reverted commit. In the body it should say:This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
Description
First line cannot be longer than 70 characters, second line is always blank and other lines should be wrapped at 80 characters.
Body
- uses the imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior
Footer
footers other than BREAKING CHANGE: <description> should follow a convention similar to git trailer format.
Conventional Commits Example
$ git log --oneline ./src/components/button/
06faab4d revert: feat: add disabled property
186cce90 feat: add disabled property
5b998d9a test: add scenario for readonly property
263288a5 fix: fix css when hover
c3fb85af feat: add button component