Generate Commit Message

Generate commit messages that follow the Conventional Commits specification by analyzing git changes.

Process

•Analyze changes: Run git diff --cached for staged changes or git diff for unstaged changes
•Determine type: Identify the primary change type from the diff
•Identify scope: Extract the affected module/component (optional but recommended)
•Write description: Create a concise, imperative-mood description
•Add body (if needed): Include context for complex changes
•Check for breaking changes: Look for API changes, removed features, or schema changes

Commit Message Format

code

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types

Type	When to Use	Example
`feat`	New feature	`feat(auth): add JWT token refresh`
`fix`	Bug fix	`fix(reports): correct date formatting`
`docs`	Documentation only	`docs: update API documentation`
`style`	Formatting, missing semicolons	`style: format code with prettier`
`refactor`	Code restructuring	`refactor(users): extract validation logic`
`perf`	Performance improvement	`perf(db): optimize query with index`
`test`	Adding/updating tests	`test(auth): add login tests`
`chore`	Build tasks, dependencies	`chore: update dependencies`
`build`	Build system changes	`build: update webpack config`
`ci`	CI/CD changes	`ci: add GitHub Actions workflow`

Scope Guidelines

•Use module/component name: feat(auth), fix(articles), refactor(database)
•Use library name for libs: feat(s3), fix(email)
•Omit scope for broad changes: chore: update dependencies
•Use lowercase, no spaces

Description Guidelines

•Use imperative mood: "add feature" not "added feature" or "adds feature"
•Lowercase (except proper nouns)
•No period at the end
•Keep under 72 characters when possible
•Be specific: "fix date parsing bug" not "fix bug"

Breaking Changes

Indicate breaking changes with ! after type/scope or BREAKING CHANGE: footer:

code

feat(api)!: change response format

BREAKING CHANGE: API now returns objects instead of arrays

Or:

code

feat!: remove deprecated endpoint

Examples

Simple feature

code

feat(auth): add password reset functionality

Bug fix with scope

code

fix(reports): correct timezone handling in date filters

Refactor with body

code

refactor(database): extract query builder logic

Move complex SQL generation to dedicated QueryBuilder class
to improve testability and maintainability.

Breaking change

code

feat(api)!: change pagination response structure

BREAKING CHANGE: Pagination now uses `page` and `per_page` instead of `offset` and `limit`

Multiple changes

If changes span multiple types, focus on the primary change or split into multiple commits:

code

feat(articles): add article categorization

- Add category field to article entity
- Update article service with category filtering
- Add category filter to article controller

Analysis Tips

•
File patterns:
- •New files → usually feat
- •Test files → test
- •Config files → chore or build
- •Documentation → docs
•
Change patterns:
- •Adding exports/endpoints → feat
- •Fixing logic errors → fix
- •Reorganizing code → refactor
- •Performance optimizations → perf
•
Scope detection:
- •Look at directory structure: src/articles/ → articles
- •Check module names: ArticlesModule → articles
- •Library modules: libs/s3/ → s3
•
Breaking changes:
- •Removed exports/functions
- •Changed function signatures
- •Changed response formats
- •Database schema changes (migrations)

Output Format

ALWAYS provide the full git commit command with the message:

bash

git commit -m "feat(scope): description"

For multi-line messages, format as:

bash

git commit -m "feat(scope): description" -m "Additional context line 1" -m "Additional context line 2"

Or use a commit message file if body is long.