commit typerefactor commit template
A commit that restructures existing code without changing its observable behaviour — no new features and no bug fixes.
format
refactor(scope): short imperative description of the restructuring
- what was restructured or extracted (bullet 1)
- what was renamed or moved (bullet 2)
- what was simplified or removed (bullet 3)
Why the refactor improves the codebase: maintainability, testability,
performance model, or alignment with current patterns. Max 72 chars/line.real examples
refactor(auth): extract token validation into standalone TokenValidator
- move verifyToken logic from AuthMiddleware into TokenValidator class
- inject TokenValidator through constructor for testability
- delete duplicate token parsing in AdminMiddleware that duplicated auth logic
AuthMiddleware had grown to 400 lines; the extraction makes token logic
independently testable and removes a duplication that had already drifted
out of sync with the main path.refactor(db): replace raw SQL strings with query builder throughout
- migrate 14 hand-crafted SELECT strings to knex query builder calls
- remove sql-template-strings dependency no longer needed after migration
- add ESLint rule to disallow new string-concatenated queries
Raw SQL strings were not type-checked and had caused two injection-adjacent
bugs in code review; the query builder provides structural guarantees and
consistent parameterisation.refactor(api): flatten nested error-handling callbacks with async/await
- convert 6 handler functions from callback pyramid to async/await
- remove custom asyncWrap helper now that all handlers are native async
- standardise error propagation via next(err) in catch blocks
Callback nesting made control flow hard to follow during code review;
async/await reduces cognitive overhead and makes the error path linear.refactor(config): consolidate environment variable reading to single module
- create src/config/index.ts that reads and validates all env vars at startup
- replace 23 scattered process.env accesses with imports from config module
- add Zod schema validation with descriptive error messages on missing vars
Scattered env reads made it impossible to see the full config surface in
one place; centralising them also moves validation to startup rather than
request time.when to use
Use refactor when the external behaviour stays the same but the internal code structure, organisation, naming, or readability improves. If any observable output changes, it is a feat or fix, not a refactor.
git-agent automatically analyzes your changes and infers the correct commit type.
brew install gitagenthq/brew/git-agentFAQ
Does refactor trigger a version bump?No. refactor commits do not trigger version bumps in standard semantic-release configuration because they represent no change in observable behaviour for users or consumers.
Should I test that behaviour is preserved after a refactor?Yes. The definition of a refactor is unchanged observable behaviour. If you don't have tests covering the refactored code, write them before refactoring. This is the essence of test-driven refactoring.
What is the difference between refactor and style commits?style covers purely cosmetic changes that do not affect logic: whitespace, formatting, missing semicolons. refactor involves meaningful structural changes to how code is organised, named, or how concerns are separated.