Conventional Commit Messages¶
If you're contributing to inline-tests, follow this format. It's how we generate changelogs and version bumps automatically.
git commit -m"<type>(<optional scope>): <description>" \
-m"<optional body>" \
-m"<optional footer>"
Note: This cheatsheet is opinionated but does not violate the Conventional Commits specification.
Commit Message Formats¶
General Commit¶
Initial Commit¶
Types¶
Changes relevant to the API or functionality:
feat— Commits that add or adjust a featurefix— Commits that fix a bug
Internal changes:
refactor— Rewrite or restructure code without changing behaviorperf— Specialrefactorthat improves performancestyle— Code style changes (whitespace, formatting) without behavior changetest— Add missing tests or correct existing onesdocs— Documentation only changesbuild— Build system, dependencies, CI/CD changesci— CI configuration changeschore— Miscellaneous (e.g.,.gitignore)
Scopes¶
The scope provides additional context. It's optional but encouraged.
inline-tests scopes:
decorator— @test/@it decoratorsplugin— pytest plugin and collectioncli— itest commandtypes— type definitions
Do not use issue identifiers as scopes.
Breaking Changes¶
Breaking changes must be indicated by ! before the ::
Or include a footer:
feat(decorator): new decorator options
BREAKING CHANGE: @test no longer accepts positional arguments
Description¶
The description is a concise summary:
- Mandatory
- Use imperative, present tense: "add" not "added" or "adds"
- Think: "This commit will... add timeout parameter"
- Do not capitalize the first letter
- Do not end with a period
Versioning Impact¶
Your commits determine the next version:
| Commit Type | Version Bump |
|---|---|
feat |
Minor (0.X.0) |
fix |
Patch (0.0.X) |
perf |
Patch (0.0.X) |
Breaking change (!) |
Major (X.0.0) |
| Others | No release |