The following is a cheatsheet on how to efficiently use conventional commits.
About the standard for writing commit messages. These can be validated with tools like commitlint and even auto-generated - see Auto Commit Message for VS Code.
From the homepage:
A specification for adding human and machine readable meaning to commit messages
<type>[optional scope]: <description>
- Conventional Commits homepage
- See this to learn more on writing Conventional Commits messages. The Summary section covers the prefixes used here.
- Commit Message Format
- In the Angular Contributing doc. The standard came out of Angular.
A prefix for the commit message describing the type of the change.
Type values allowed
This should be only one of the types defined in the standard.
I’ve grouped them as they make sense to me.
- Supplemental (the app can still run locally without these)
ci- update workflow for CI.
test- relating to running tests.
chore- like configs and file renames or moves.
Check these pages to see officially allowed types.
- Type section on the Angular repo. This is linked from the Conventional Commits website as “Angular Convention”. It explains what
- Allowed types defined in the docs of the
config-conventionalsection of the
commitlintrepo. This presumably works closely or exactly to the Angular standard.
Here are some less offical guides for more help.
Here is an example of the feature type used as a prefix.
feat: add foo
A documentation change:
docs: fix typo in foo.md and bar.md
From the docs:
Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space.
The standard defines use of an optional scope, which is used in additional to the required type.
From the docs:
An optional scope MAY be provided after a type.
A scope is a phrase describing a section of the codebase enclosed in parenthesis.
e.g. ‘fix(parser):’ This would be specific to a particular project, so you cannot know the generalize scopes for all projects. The standard says you should agree in your team what the scopes would be. Perhaps based on features, projects or directories.
I believe there are some scope values which do generalize well.
All dependency changes can have scope of
Some possible examples.
build(deps): upgrade packages
style(deps): remove whitespace in requirements.txt
fix(deps): correct typo in package.json package name
Perhaps updating test dependencies would be under test rather than build.
#reads #michael currin #git #conventional commits #cheatsheet