Git Commit Message Generator

Writing Conventional Commit Messages

Conventional Commits is a specification that adds structure to commit messages. By prefixing each commit with a type and optional scope, teams create a machine-readable commit history. This structure enables automated changelog generation, semantic version bumping, and easier code review. The format follows a simple pattern: type(scope): description.

The type indicates the nature of the change. Use feat for new features and fix for bug fixes. These two types are special because they correspond to MINOR and PATCH version increments in semantic versioning. Other types like docs, refactor, test, and chore provide additional categorization without affecting the version number.

Commit Message Structure

A complete conventional commit has three parts: the header, an optional body, and an optional footer. The header is the first line containing the type, scope, and description. The body, separated by a blank line, explains the motivation behind the change. The footer contains metadata like breaking change descriptions and issue references.

Best Practices

Write the description in imperative mood: "add feature" not "added feature" or "adds feature." Keep it under 72 characters. Start with lowercase. Do not end with a period. If the commit needs explanation, add a body describing why the change was made, not what was changed. The code diff already shows what changed; the commit message should explain the reasoning.

Breaking Changes

A breaking change introduces incompatible modifications to the public API. Mark it with an exclamation after the type (feat!:) and include a BREAKING CHANGE: footer with a description. This triggers a major version bump and alerts consumers that they may need to update their code to accommodate the change.

Frequently Asked Questions

What are conventional commits?

A structured format for commit messages using type(scope): description. Enables automated changelogs and semantic versioning.

What types are available?

feat, fix, docs, style, refactor, perf, test, build, ci, chore, and revert. feat and fix affect version numbers.

What is a breaking change?

An incompatible API change marked with ! and a BREAKING CHANGE footer. Triggers a major version bump in semver.

Should the description be uppercase or lowercase?

Lowercase, imperative mood, no period. For example: "add user authentication" not "Added user authentication."

How long should the message be?

The header should be under 72 characters. Use the body for longer explanations, focusing on why the change was made.