27 lines
1.2 KiB
Plaintext
27 lines
1.2 KiB
Plaintext
---
|
|
description: Git commit messages and how to split work into commits
|
|
alwaysApply: true
|
|
---
|
|
|
|
# Commits
|
|
|
|
When preparing commits (especially when the user asks to commit):
|
|
|
|
1. **Prefer multiple commits** over one large commit when changes span distinct concerns (e.g. UI vs docs vs API). One logical unit per commit.
|
|
2. **Message format:** `type(scope): short imperative subject` (lowercase subject after the colon; no trailing period).
|
|
- **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf` (use what fits).
|
|
- **Scope:** optional but encouraged — e.g. `ui`, `api`, `profiles`, `presets`, `esp32`.
|
|
3. **Subject line:** ~50 characters or less; describe *what* changed, not the ticket number alone.
|
|
4. **Body:** only when needed (breaking change, non-obvious rationale, or multiple bullets). Otherwise subject is enough.
|
|
|
|
**Examples**
|
|
|
|
- `feat(ui): gate profile delete to edit mode`
|
|
- `docs: document run vs edit in API`
|
|
- `fix(api): resolve preset delete route argument clash`
|
|
|
|
**Do not**
|
|
|
|
- Squash unrelated fixes and doc tweaks into one commit unless the user explicitly wants a single commit.
|
|
- Use vague messages like `update`, `fixes`, or `wip`.
|