commit type

style commit template

A commit that makes purely cosmetic changes to code formatting with no effect on logic: whitespace, indentation, semicolons, trailing commas, or quote style.

format

style(scope): short imperative description of what was formatted

- what formatter or linter rule was applied (bullet 1)
- scope of files affected if not obvious from the diff (bullet 2)

Why the formatting change was needed: new formatter configuration,
pre-commit hook enforcement, or codebase-wide consistency pass.

real examples

style(src): apply prettier 3.2 formatting across all source files

- run prettier --write on src/ after upgrading from 3.0 to 3.2
- printWidth changed from 80 to 100 per updated .prettierrc.json
- no logic changes; all tests pass unchanged

Prettier 3.2 adjusts object destructuring and ternary formatting rules;
running the formatter now prevents churn on subsequent PRs.

style(api): enforce double quotes throughout with ESLint fix

- run eslint --fix on api/ to apply quotes: ["error", "double"] rule
- 47 files updated; no mixed-quote strings remain in the module
- add the rule to .eslintrc.json so it is enforced going forward

Single and double quotes were mixed inconsistently; the ESLint rule makes
the style machine-enforceable and removes style discussions from review.

style(go): run gofmt and goimports on all packages

- format all .go files with gofmt -w
- sort and group imports with goimports
- no semantic changes; go vet passes with no new warnings

New contributors were adding files without running gofmt; adding a
pre-commit hook requires all files to be formatted first.

style(python): apply black formatting with line-length 88

- run black src/ tests/ with --line-length 88
- add pyproject.toml [tool.black] section with the same configuration
- resolve the one pre-existing black disagreement in utils.py manually

The codebase had no enforced formatter; this establishes black as the
canonical formatter and unblocks adding it to the pre-commit config.

when to use

Use style exclusively for changes that a formatter or linter makes automatically, with zero logic change. If you rename a variable while reformatting, that is a refactor, not a style commit.

git-agent automatically analyzes your changes and infers the correct commit type.

brew install gitagenthq/brew/git-agent

FAQ

Should style commits be separated from other types?

Yes. Mixing formatting changes with logic changes makes diffs harder to review. Run the formatter first, commit the style changes, then make your logic changes in a separate commit.

Does style appear in the changelog?

No. style commits are excluded from all standard changelog presets because they carry no information relevant to users or API consumers.

Is adding an end-of-file newline a style commit?

Yes, if it is the only change. EOL normalisation, trailing whitespace removal, and line ending conversion (CRLF to LF) are all style changes.

What are Conventional Commits?Pre-commit hooks refactor commit template