glossaryA lightweight specification for commit message formatting that encodes change type, scope, and description in a structured, machine-readable way.
The Conventional Commits specification defines a standard commit message structure: a required type, an optional scope in parentheses, and a mandatory subject line, optionally followed by a blank line and a longer body. Common types include feat (new functionality), fix (bug corrections), docs (documentation only), refactor (code restructuring without behaviour change), test, chore, perf, style, and ci. The specification enables changelog generation tools to automatically categorise changes, and semantic versioning tools to determine the next version number from commit history. A feat commit implies a minor version bump; a fix implies a patch; and a commit with a BREAKING CHANGE footer implies a major bump. Teams adopting Conventional Commits benefit from a shared vocabulary for change intent, reviewable history, and automated release workflows. The specification is maintained at conventionalcommits.org and widely supported by tools such as semantic-release, release-please, and conventional-changelog.
feat(auth): add OAuth2 PKCE flow for public clientsfix(api): return 404 instead of 500 when user record is missingrefactor(cache): replace in-memory store with Redis adapterdocs(readme): add installation instructions for Linuxchore(deps): upgrade express from 4.18.2 to 4.19.2git-agent generates fully-formed Conventional Commits messages automatically from your staged diff. It selects the appropriate type and scope, writes the subject line, and drafts a bullet-point body explaining what changed and a closing paragraph explaining why.
brew install gitagenthq/tap/git-agentIs the Conventional Commits specification the same as Angular commit guidelines?Do I need to use all the commit types?Can I use Conventional Commits without automated tooling?