João Freitas

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>

[optional body]

[optional footer]



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.

Check these pages to see officially allowed types.


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 and

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 deps.

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