conventional-commits

Standardize git commit messages by enforcing the Conventional Commits specification, which structures messages with a type, optional scope, and short subject to enable automatic changelog generation and semantic versioning.

A conventional commit message requires a type, an optional scope, and a subject under 72 characters, followed by an optional body and footer to document breaking changes and metadata for release notes.

Mark breaking changes in conventional commits by adding an exclamation mark after the type or scope, or by including a 'BREAKING CHANGE:' footer, ensuring semantic versioning pipelines trigger a major version bump.

Yes, conventional commits applies across software development workflows including pull requests, rebases, and squash merges, ensuring team-wide commit history consistency for automated release notes generation.

Use conventional commits for semantic versioning because it provides strict formatting rules for commit types and breaking changes, allowing automated pipelines to parse history and determine version bumps accurately.

The limitation of enforcing conventional commits is that it requires strict adherence without exception to formatting rules like subject length under 72 characters, which may disrupt existing team workflows if not fully adopted.