Git Commit Standards

# Git Commit Standards

## Commit Message Format

Use the Conventional Commits specification:

```
<type>(<scope>): <description>

[optional body]

[optional footer(s)]
```

## Commit Types

- **feat**: A new feature for the user
- **fix**: A bug fix for the user
- **docs**: Documentation only changes
- **style**: Formatting, missing semicolons, etc (no code change)
- **refactor**: Code change that neither fixes a bug nor adds a feature
- **perf**: Performance improvements
- **test**: Adding or correcting tests
- **chore**: Maintenance tasks, dependencies, build changes

## Guidelines

### Description
- Use imperative mood: "Add feature" not "Added feature"
- Keep under 72 characters
- Don't end with a period
- Be specific and descriptive

### Body (Optional)
- Explain the motivation for the change
- Contrast with previous behavior
- Wrap at 72 characters

### Breaking Changes
- Add `BREAKING CHANGE:` in footer
- Or append `!` after type: `feat!: remove deprecated API`

## Examples

```
feat(auth): add OAuth2 login with Google

Implements Google OAuth2 authentication flow with proper
token refresh handling and session management.

Closes #123
```

```
fix(api): handle null response in user endpoint

Previously the endpoint would crash when the user
had no profile data. Now returns empty object.
```

```
refactor(components): extract shared button styles

Consolidates duplicate button styling into a single
reusable component to improve maintainability.
```

## Branch Naming

- `feature/` - New features
- `fix/` - Bug fixes
- `hotfix/` - Urgent production fixes
- `refactor/` - Code improvements
- `docs/` - Documentation updates

Use kebab-case: `feature/user-authentication`

## Pull Request Guidelines

- Keep PRs focused and small (under 400 lines when possible)
- Write descriptive PR titles following commit conventions
- Include context in PR description
- Link related issues
- Request reviews from relevant team members
- Squash commits when merging feature branches