conventional-commits

# conventional-commits

Reference guide for the Conventional Commits specification used by release-notes-gen.

## Format

```
type(scope): description

[optional body]

[optional footer]
```

## Commit Types

| Type | When to Use | Bump |
|---|---|---|
| `feat` | New user-facing feature | minor |
| `fix` | Bug fix | patch |
| `perf` | Performance improvement | patch |
| `refactor` | Code restructure, no behavior change | none |
| `docs` | Documentation only | none |
| `style` | Formatting, whitespace | none |
| `test` | Add or fix tests | none |
| `build` | Build system, dependencies | none |
| `ci` | CI/CD configuration | none |
| `chore` | Maintenance, tooling | none |

## Examples

### Feature

```
feat(auth): add OAuth2 login support
```

### Bug Fix

```
fix(ui): align button correctly on mobile Safari
```

### Breaking Change (two forms)

Using `!` after type:
```
feat!: remove support for Node 18
```

Using footer:
```
feat(api): change response format

BREAKING CHANGE: the `data` field is now an array instead of object.
Clients must update to handle the new format.
```

### With Scope

```
fix(database): handle null value in user query
feat(cli): add --dry-run flag
docs(readme): add quickstart section
```

### Without Scope

```
fix: prevent crash on empty input
chore: update dependencies
```

## How rng Uses Commit Messages

**Version bump calculation** - rng scans all commits since the last tag and computes the highest applicable bump: breaking=major, feat=minor, fix/perf=patch.

**Section grouping** - Commits grouped by type into sections in the release notes. feat commits go under "Features", fix under "Bug Fixes", etc.

**Hidden types** - chore, docs, style, test, build, ci, refactor are hidden by default (not shown in release notes unless `--include-all` is used). Customize in `.rng.json`.

**Non-conforming commits** - Commits that do not follow the format are grouped as type `other` and hidden by default.

## Tips

- Use scope for module/area: `fix(auth):`, `feat(api):`, `docs(readme):`
- Keep description short (under 72 chars) and in imperative mood: "add" not "added"
- Use body for longer explanation when needed
- Use `BREAKING CHANGE:` footer when the breaking change needs explanation beyond the description line