Semantic Commit Messages

semantic-commit-messages.md

Conventional Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example

feat(model):add new shoes object to app

fix(model):forgot to add shoelaces

docs(model):sholeaces added to my favourite wiki

refactor(controller):implement lacing of shoes

feat(scope):add hat wobble
^--^   ^    ^------------^
|      |    |
|      |    +-> Summary in present tense.
|      +-> Optional scope of software being affected, controller, mailer, logical other...
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

More Examples:

• feat: (new feature for the user, not a new feature for build script)
• fix: (bug fix for the user, not a fix to a build script)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)
• bump: (version update)
• ci: (changes to the build config)
• deploy: (deployment commit details if using github actions)
• build: (changes that affect the build system or external dependencies)

References:

• https://www.conventionalcommits.org/
• https://seesparkbox.com/foundry/semantic_commit_messages
• http://karma-runner.github.io/1.0/dev/git-commit-msg.html

prettifying github releases:

• https://github.com/bcoe/conventional-release-labels
• https://github.com/semantic-release/semantic-release

in the wild:

• https://platform.deloitte.com.au/articles/semantic-versioning-with-conventional-commits