Semantic commit messages allow for automated versioning, changelog generation, and GitHub releases using tools like semantic-release.
- Enables automatic tagging (e.g.
v1.2.3) - Generates CHANGELOG.md automatically
- Triggers CI/CD workflows smartly
- Improves collaboration and traceability
<type>[optional scope]: <short description>
[optional body]
[optional footer(s)]
| Type | Purpose |
|---|---|
feat |
New feature |
fix |
Bug fix |
chore |
Maintenance, build process, config or minor tasks (no user impact) |
docs |
Documentation only changes |
refactor |
Code changes that neither fix a bug nor add a feature |
test |
Adding or improving tests |
perf |
Performance improvement |
style |
Formatting, missing semicolons, indentation... |
ci |
CI/CD configuration or scripts |
revert |
Revert to a previous commit |
BREAKING CHANGE: |
Special footer to signal major version bump |
feat(api): add forecasting endpoint for batch predictions
fix(train): handle empty dataset edge case during model training
docs(readme): update setup instructions for MLflow
refactor(data): clean up processing script and modularize logic
feat(train): switch from sklearn to XGBoost training
BREAKING CHANGE: the training module now outputs XGBoost models instead of sklearn ones.
- Keep commit messages short (max 72 chars)
- Use imperative tone:
add,fix,update, notadded,fixed - Include body only when necessary (e.g., complex changes)
- Use
BREAKING CHANGE:footer only when it affects public APIs or expected usage
When merged into main, semantic-release will:
- Determine the next version (based on commit types)
- Create a GitHub tag (
vX.Y.Z) - Update
CHANGELOG.md - Create a GitHub Release
🧠 Be consistent. Be semantic. Let automation work for you!