# Git Workflow

## Commit Messages
- Follow conventional commits: `type(scope): subject`.
- Types: feat, fix, refactor, docs, test, chore, perf, style, ci.
- Subject line: imperative mood, lowercase, no period, max 72 characters.
- Body: explain why, not what. Wrap at 80 characters.
- Reference issues: `Closes #123` or `Relates to #456`.

## Branching
- Create feature branches from main: `feature/short-description`.
- Use prefixes: `feature/`, `fix/`, `chore/`, `refactor/`, `docs/`.
- Keep branches short-lived. Merge within 1-3 days.
- Delete branches after merging.

## Pull Requests
- One logical change per PR. Do not bundle unrelated changes.
- Keep PRs under 400 lines of diff when possible.
- Write a description explaining the motivation, not just the changes.
- Include a test plan describing how to verify the change.
- Request review from at least one person.
- Address all review comments before merging.

## Merge Strategy
- Squash merge for feature branches (clean history).
- Merge commit for release branches (preserve history).
- Never force push to main or shared branches.
- Rebase feature branches on main before merging to resolve conflicts.

## Safety Rules
- Never commit secrets, credentials, or API keys.
- Never commit large binary files. Use Git LFS if needed.
- Never commit generated files (dist/, build/, node_modules/).
- Always review `git diff --cached` before committing.
- Run tests before pushing. If CI fails, fix before merging.

## Tags and Releases
- Use semantic versioning: MAJOR.MINOR.PATCH.
- Tag releases on main: `git tag -a v1.2.3 -m "Release 1.2.3"`.
- Write release notes summarizing changes since last release.