Sentry Commit Conventions

When to Use This Skill

• Making git commits
• Writing commit messages
• Organizing changes into commits
• Preparing code for review

Commit Message Format

<type>(<scope>): <subject>

<body>

<footer>

Types

Type	Description	Example
feat	New feature	feat(auth): add SSO login
fix	Bug fix	fix(api): handle null response
docs	Documentation	docs(readme): update setup guide
style	Formatting	style(lint): fix indentation
refactor	Code restructure	refactor(db): extract query builder
perf	Performance	perf(cache): add redis caching
test	Tests	test(auth): add login tests
build	Build system	build(deps): upgrade webpack
ci	CI/CD	ci(github): add lint workflow
chore	Maintenance	chore: update gitignore
revert	Revert commit	revert: feat(auth): add SSO

Scope

The scope should be the module, component, or area affected:

feat(auth): ...       # Authentication module
fix(api/users): ...   # Users API endpoint
docs(contributing): ...  # Contributing docs
refactor(ui/button): ... # Button component

Subject Line Rules

## Good Subject Lines
- Start with lowercase (unless proper noun)
- No period at the end
- Use imperative mood ("add" not "added")
- Keep under 50 characters
- Be specific and descriptive

## Examples
✅ feat(auth): add password reset flow
✅ fix(api): handle rate limit errors gracefully
✅ refactor(db): extract connection pooling logic

❌ feat(auth): Added password reset flow.
❌ fix: fix stuff
❌ refactor(db): this refactors the database connection pooling logic to be more efficient

Body (Optional but Recommended)

fix(api): handle rate limit errors gracefully

The API was crashing when receiving 429 responses from
the upstream service. This adds proper error handling
and implements exponential backoff.

- Add RateLimitError exception class
- Implement retry logic with exponential backoff
- Add circuit breaker for repeated failures
- Log rate limit events for monitoring

Footer

# Reference issues
Fixes #123
Closes #456
Refs #789

# Breaking changes
BREAKING CHANGE: API response format changed

The `user` field is now `users` (array) in the response.
Migration guide: https://docs.example.com/migration

Atomic Commits

Principles

## Each Commit Should:
1. Represent one logical change
2. Leave the codebase in a working state
3. Be independently reviewable
4. Be revertable without side effects

Example: Breaking Up Changes

# Instead of one large commit:
# "feat: add user management"

# Break into atomic commits:
git commit -m "feat(db): add users table migration"
git commit -m "feat(models): add User model with validation"
git commit -m "feat(api): add user CRUD endpoints"
git commit -m "feat(ui): add user management page"
git commit -m "test(users): add integration tests"
git commit -m "docs(api): document user endpoints"

Git Workflow

Staging Changes

# Stage specific files
git add src/auth/login.ts src/auth/logout.ts

# Interactive staging (pick hunks)
git add -p

# Stage all changes (be careful!)
git add .

Creating Commits

# Quick commit with message
git commit -m "type(scope): subject"

# Open editor for detailed message
git commit

# Amend last commit (before push)
git commit --amend

# Amend without changing message
git commit --amend --no-edit

Before Committing

# Review what's staged
git diff --staged

# Check status
git status

# Run tests
npm test

# Run linter
npm run lint

Commit Message Templates

Feature

feat(scope): add feature description

Implement [feature] to enable [capability].

- Add [component/function]
- Update [related component]
- Include [tests/docs]

Closes #123

Bug Fix

fix(scope): resolve issue description

The issue occurred because [root cause].
This fix [explanation of solution].

Before: [problematic behavior]
After: [correct behavior]

Fixes #456

Refactor

refactor(scope): improve code description

Restructure [component] to improve [quality attribute].

Changes:
- Extract [function/class]
- Rename [old name] to [new name]
- Remove unused [code]

No functional changes.

Breaking Change

feat(api)!: change authentication method

BREAKING CHANGE: JWT tokens now required for all API calls.

Migration:
1. Generate API key in dashboard
2. Include in Authorization header
3. Update client SDK to v2.0+

See migration guide: https://docs.example.com/auth-migration

Commit Hooks

Pre-commit

#!/bin/bash
# .git/hooks/pre-commit

# Run linter
npm run lint || exit 1

# Run type check
npm run typecheck || exit 1

# Run tests
npm test -- --passWithNoTests || exit 1

Commit-msg

#!/bin/bash
# .git/hooks/commit-msg

MSG=$(cat "$1")
PATTERN="^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?(!)?: .{1,50}"

if ! echo "$MSG" | grep -qE "$PATTERN"; then
  echo "❌ Invalid commit message format"
  echo "Expected: type(scope): subject"
  exit 1
fi

Best Practices

• One logical change per commit
• Write clear, descriptive messages
• Reference related issues
• Test before committing
• Don't commit secrets or sensitive data
• Keep commits small and focused
• Use imperative mood in subjects
• Explain "why" in the body