Conventional Commits

To trigger automated semantic versioning with release-please, format commit messages using strict Conventional Commits with a lowercase type, imperative mood, and correct breaking-change markers like `!` or `BREAKING CHANGE:` footers to ensure predictable version bumps.

The correct structure for conventional commit messages requires a lowercase type, a lowercase-starting description without trailing periods, an optional leading emoji, and imperative mood. This structure ensures automated release-please versioning behaves predictably without accidental formatting violations.

To signal a breaking change for a MAJOR release in conventional commits, append a `!` after the type or add a `BREAKING CHANGE:` footer. Using a `feat:` type without breaking markers triggers a MINOR release, while `fix:` triggers a PATCH.

Yes, you can use one optional leading gitmoji prefix in commit messages as a cosmetic enhancement. Release-please versioning behavior remains determined solely by the conventional commit type, ensuring the emoji does not interfere with automated semantic version bumps.

To validate existing commit messages, check them against release-please compatible formatting rules, ensuring they use lowercase types, imperative mood, no trailing periods in titles, and proper breaking-change markers to prevent release-triggering mistakes.

A limitation of conventional commit formatting is that strict adherence is mandatory; any formatting violation, such as an uppercase type or trailing period, can prevent release-please from correctly parsing the commit and triggering the intended semantic version bump.