gitlisted

# Git Commit ## Conventional Commits Format ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ### Commit Types - `feat`: New features (correlates with MINOR in semantic versioning) - `fix`: Bug fixes (correlates with PATCH in semantic versioning) - `docs`: Documentation only changes - `refactor`: Code changes that neither fix bugs nor add features - `perf`: Performance improvements - `test`: Adding or modifying tests - `chore`: Maintenance tasks, dependency updates, etc. - `style`: Code style changes (formatting, missing semicolons, etc.) - `build`: Changes to build system or dependencies - `ci`: Changes to CI configuration files and scripts ### Scope Guidelines - **Scope is OPTIONAL**: only add when it provides clarity - Use lowercase, placed in parentheses after type: `feat(transcription):` - Prefer specific component/module names over generic terms - Your current practice is good: component names (`EditRecordingDialog`), feature areas (`transcription`, `sound`) - Avoid overly generic scopes like `ui` or `backend` unless truly appropriate ### When to Use Scope - When the change is localized to a specific component/module - When it helps distinguish between similar changes - When working in a large codebase with distinct areas ### When NOT to Use Scope - When the change affects multiple areas equally - When the type alone is sufficiently descriptive - For small, obvious changes ### Description Rules - Start with lowercase immedi