git_commit.md

I. Commit rules

General Best Practices

1. Single Responsibility

• Each commit should contain related changes only
• If you find yourself using "and" in your commit message, consider splitting it

2. Size Matters

• Keep commits small and focused
• Aim for changes that can be described in 50 characters or less

3. Logical Units

• Commits should represent logical units of change
• Someone should be able to understand what changed and why from your commit

4. When to Create a New Commit

• When completing a distinct step toward your goal
• When making changes that could be rolled back independently
• When switching between different types of changes (e.g., from feature work to bug fixing)

II. Commit format

• Commit prefixes

feat: new feature
fix: bug fix
docs: documentation changes
style: formatting, missing semi colons, etc (no code change)
refactor: refactoring code
test: adding tests, refactoring tests
chore: updating build tasks, package manager configs, etc
perf: performance improvements
ci: CI related changes
build: changes that affect the build system
revert: reverting a previous commit

• Basic format:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• Examples:

feat(auth): add login with Google OAuth
fix(api): handle null response from users endpoint 
docs: update README installation steps
refactor(cart): simplify checkout flow
test(auth): add unit tests for password validation

• Best practices:
  • Use imperative mood in description ("add" not "added")
  • Don't capitalize first letter of description
  • No period at end of description
  • Keep description under 50 characters
  • Add detailed explanation in body if needed
  • Reference issues/PRs in footer

feat: new feature

• When to use: Adding new functionality to your application

✅ Good:
feat(auth): add login form component
feat(products): create shopping cart functionality
feat(api): add endpoint for user preferences

❌ Avoid:
feat: multiple unrelated features
feat: big feature with many changes (break it down!)

fix: bug fixes

• When to use: Fixing a bug or error in existing code

✅ Good:
fix(checkout): calculate total price correctly
fix(ui): prevent modal from closing unexpectedly
fix(auth): handle expired token refresh

❌ Avoid:
fix: multiple bug fixes
fix: weekend bug fixes (separate them!)

docs: Documentation

• When to use: Changes to documentation only

✅ Good:
docs: add API authentication guide
docs(setup): update installation steps
docs(components): add JSDoc for Button component

❌ Avoid:
docs: various documentation updates
docs: fix typos everywhere

style: Code Style

• When to use: Changes that don't affect code behavior

✅ Good:
style: format user service using prettier
style(css): align header elements
style: remove trailing whitespace

❌ Avoid:
style: fix various style issues
style: cleanup (too vague!)

refactor: Code Refactoring

• When to use: Restructuring existing code without changing its behavior

✅ Good:
refactor(auth): extract validation logic to separate service
refactor: convert class components to functional
refactor(api): use async/await instead of promises

❌ Avoid:
refactor: massive code reorganization
refactor: cleanup old code

test: Testing Changes

• When to use: Adding or modifying tests

✅ Good:
test(auth): add unit tests for password validation
test(api): update user service mocks
test: add integration tests for checkout flow

❌ Avoid:
test: add more tests
test: fix broken tests

chore: Maintenance

• When to use: Changes to build process or auxiliary tools
• More examples:
  • Update .gitignore file
  • Updating editor configs (.editorconfig)
  • Modifying build scripts
  • Updating package.json metadata
  • Configuring linting rules
  • Managing development dependencies

✅ Good:
chore(deps): update react to v18
chore: add eslint configuration
chore(scripts): add database seed script

❌ Avoid:
chore: various updates
chore: cleanup

perf: Performance

• When to use: Code changes that improve performance

✅ Good:
perf(queries): add index for faster user search
perf(images): implement lazy loading
perf(api): add response caching

❌ Avoid:
perf: various optimizations
perf: make it faster