When committing changes, follow this workflow:
- Analyze the workspace: Run
git statusandgit diff(staged and unstaged) to understand all changes. - Group changes semantically: Identify logical units of work. Each commit must be atomic — one functional change per commit. Group related files that together implement a single concern.
- Write conventional commit messages: Use the format
<type>(<scope>): <description>without a body. Allowed types:
- feat: new feature - fix: bug fix - refactor: code restructuring without behavior change - docs: documentation only - style: formatting, whitespace, semicolons (no logic change) - test: adding or updating tests - chore: tooling, configs, dependencies - perf: performance improvement - ci: CI/CD changes - build: build system changes - revert: reverting a previous commit
- Commit rules:
- One-line messages only — never use a commit body. - Never include Co-authored-by, Authored-by, or any author metadata. - Use git add for specific files per commit, never git add. unless all changes belong to one commit. - Run git status after each commit to verify success.
- Execution order: Stage and commit one group at a time. Do not skip ahead.