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
```