# Git Commit Standards

## Commit Message Format

### Basic Structure

[type] [ticket_number] description
(leave an extra line here)
- additional details 1 (optional)
- additional details 2 (optional)

## Commit Types

| Type | Description | When to Use |
|------|-------------|-------------|
| **feat** | New feature | Adding new functionality or capabilities |
| **fix** | Bug fix | Fixing defects, errors, or issues |
| **docs** | Documentation | Updates to README, comments, or documentation files |
| **style** | Code style | Formatting, white-space, missing semi-colons (no logic changes) |
| **refactor** | Code refactoring | Restructuring code without changing functionality |
| **test** | Testing | Adding or updating tests |
| **chore** | Maintenance | Build tasks, dependency updates, tooling changes |

## Guidelines

### Description Rules
- Use **imperative mood** (command form)
- Start with capital letter
- No period at the end
- Be concise but descriptive
- Maximum ~50 characters for the subject line

### Good Examples
- `Add payment gateway integration`
- `Fix null pointer exception in user service`
- `Update API documentation for v2 endpoints`
- `Refactor authentication middleware`

### Bad Examples
- `added payment gateway` (past tense)
- `Adding payment gateway` (gerund form)
- `fixed a bug` (too vague)
- `updates` (too generic)

## Best Practices

1. **Be Atomic**: Each commit should represent a single logical change
2. **Be Descriptive**: Others should understand what changed without reading the code
3. **Use Consistent Formatting**: Follow the established pattern
4. **Include Context**: Use the details section for complex changes
5. **Reference Issues**: Include ticket numbers when available
6. **Review Before Committing**: Ensure the message accurately describes the changes