Conventional Commits Cheatsheet

conventional-commits.md

Quick examples

• feat: new feature
• fix(scope): bug in scope
• feat!: breaking change / feat(scope)!: rework API
• chore(deps): update dependencies

Commit types

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Changes which doesn't change source code or tests e.g. changes to the build process, auxiliary tools, libraries
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• revert: Revert something
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

Reminders

• Put newline before extended commit body
• More details at conventionalcommits.org

There is a typo. It should be chore: Changes which ...
instead of chore: Changes wich

Thanks, now fixed!

Suggestions:

1. Add a quick & convenient link to the official guide: https://www.conventionalcommits.org/en/v1.0.0/
2. Under Quick Examples, add an additional example for breaking changes (or modify the existing one) to show how the exclamation point also goes after the scope, if present. You show feat!: but maybe also show feat(scope)!:.

Added your suggestions.

Suggestions:
Adding vendor type, which is used for updating dependencies/packages.

Suggestions: Adding vendor type, which is used for updating dependencies/packages.

Updating dependencies/packages is under "chore" prefix, isn't it?

I personally use build for packages/dependencies, since they're involved in the build process. But I think the point here is that we shouldn't add custom conventions beyond what is documented in the Angular repo or conventionalcommits.org.

and what about the first commit? Should it be chore?

and what about the first commit? Should it be chore?

I use "style: add empty .gitignore".
Adding an empty .gitignore file is a good first commit because it has no content and gives you a first revision with essentially nothing in it to refer back to.