Grouping Commits by Type
Understand how the Changelog Generator groups Conventional Commits by type into organized sections with a consistent ordering.
Detailed Explanation
How Commit Grouping Works
The Changelog Generator parses each commit line and extracts the type prefix (everything before the optional scope and colon). Commits with the same type are collected into a single group, and groups are rendered as sections in a predefined order.
Predefined Type Order
Sections appear in this order, regardless of the order commits appear in the input:
- feat — Features (new functionality)
- fix — Bug Fixes (corrections)
- perf — Performance Improvements
- refactor — Code Refactoring
- docs — Documentation
- style — Styles (formatting, no logic change)
- test — Tests
- build — Build System
- ci — CI/CD
- chore — Chores (maintenance)
- revert — Reverts
Why This Order?
Features and fixes are the changes most relevant to end users, so they appear first. Performance improvements and refactors are next because they affect the codebase quality. Documentation, style, test, build, and CI changes are progressively more internal. Reverts come last as they undo previous changes.
Handling Unknown Types
If a commit uses a type not in the predefined list (e.g., security: patch XSS vulnerability), it is still parsed and included. Unknown types appear after the standard types and use the raw type name as the section heading.
Empty Groups
If no commits match a particular type, that section is omitted entirely from the output. This keeps the changelog clean and focused on what actually changed.
Use Case
Useful for understanding the internal logic of the generator and customizing the output. Teams that want a specific ordering can reorder their input, but the generator enforces a consistent structure regardless.