Conventional Commit
Produce commit messages that follow the
Conventional Commits specification:
type(scope): description.
Workflow
- Run
git status to review changed files.
- Run
git diff (or git diff --cached) to inspect the changes — the message must describe
what the diff actually does.
- Stage only the files that belong to this change:
git add <file>.
- Construct the message with the structure below and commit:
git commit -m "type(scope): description" (multi-line body/footer when needed).
- Stop there — never push, open, or merge a PR/MR; that is always a human action.
Message structure
type(scope): description
[optional body — the why and any context the diff doesn't show]
[optional footer — BREAKING CHANGE: details, or issue references]
- type — one of
feat, fix, docs, style, refactor, perf, test, build, ci,
chore, revert. Append ! for breaking changes (feat!:).
- scope — optional but recommended: the module/area touched (e.g.
auth, parser, ui).
- description — required, short, imperative mood ("add", not "added"/"adds"), no
trailing period.
- body — optional; explain motivation and contrast with previous behavior.
- footer —
BREAKING CHANGE: <details> and/or issue references (Closes #123).
Examples
feat(parser): add ability to parse arrays
fix(ui): correct button alignment
docs: update README with usage instructions
refactor: improve performance of data processing
chore: update dependencies
feat!: send email on registration (BREAKING CHANGE: email service required)
Validation
Before committing, check: the type is in the allowed list, the description is imperative and
matches the staged diff, breaking changes carry ! and a BREAKING CHANGE: footer, and the
commit contains only the files of this one logical change (split unrelated changes into
separate commits).
1---2name: conventional-commit3description: Conventional Commit4---56# Conventional Commit78Produce commit messages that follow the9[Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#specification):10`type(scope): description`.1112## Workflow13141. Run `git status` to review changed files.152. Run `git diff` (or `git diff --cached`) to inspect the changes — the message must describe16 what the diff actually does.173. Stage only the files that belong to this change: `git add <file>`.184. Construct the message with the structure below and commit:19 `git commit -m "type(scope): description"` (multi-line body/footer when needed).205. Stop there — never push, open, or merge a PR/MR; that is always a human action.2122## Message structure2324```25type(scope): description2627[optional body — the why and any context the diff doesn't show]2829[optional footer — BREAKING CHANGE: details, or issue references]30```3132- **type** — one of `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`,33 `chore`, `revert`. Append `!` for breaking changes (`feat!:`).34- **scope** — optional but recommended: the module/area touched (e.g. `auth`, `parser`, `ui`).35- **description** — required, short, **imperative mood** ("add", not "added"/"adds"), no36 trailing period.37- **body** — optional; explain motivation and contrast with previous behavior.38- **footer** — `BREAKING CHANGE: <details>` and/or issue references (`Closes #123`).3940## Examples4142```43feat(parser): add ability to parse arrays44fix(ui): correct button alignment45docs: update README with usage instructions46refactor: improve performance of data processing47chore: update dependencies48feat!: send email on registration (BREAKING CHANGE: email service required)49```5051## Validation5253Before committing, check: the type is in the allowed list, the description is imperative and54matches the staged diff, breaking changes carry `!` and a `BREAKING CHANGE:` footer, and the55commit contains only the files of this one logical change (split unrelated changes into56separate commits).
jgamaraalv