Open
Description
I noticed that the cu merge has a bunch of commits that don't follow semantic commits. This would definitely help
Here are semantic commit message best practices:
Format Structure
<type>(<scope>): <subject>
<body>
<footer>
Types
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Code style changes (formatting, semicolons, etc.)
- refactor: Code refactoring without changing functionality
- perf: Performance improvements
- test: Adding or modifying tests
- build: Build system or dependency changes
- ci: CI/CD configuration changes
- chore: Routine tasks, maintenance
Subject Line Rules
- Length: Keep under 50 characters
- Tense: Use imperative mood ("add feature" not "added feature")
- Capitalization: Start with lowercase
- Punctuation: No period at the end
- Content: Complete the sentence "If applied, this commit will..."
Body Guidelines
- Line length: Wrap at 72 characters
- Content: Explain what and why, not how
- Blank line: Separate subject from body
- Bullet points: Use
-or*for lists - Context: Include motivation for the change and contrasts with previous behavior
Footer Elements
- Breaking changes: Start with
BREAKING CHANGE: - Issue references: Use
Fixes #123,Closes #456 - Co-authors:
Co-authored-by: Name <email>
Examples
Simple commit
fix(auth): correct password validation regex
Detailed commit
feat(api): add user profile endpoint
- Implement GET /api/users/:id/profile
- Add authentication middleware
- Include user preferences in response
- Cache responses for 5 minutes
Fixes #234
Breaking change
refactor(api): change user endpoint response format
Modified the /api/users endpoint to return a nested
data structure instead of flat object for better
organization and future extensibility.
BREAKING CHANGE: API response structure has changed.
Consumers need to update their parsing logic.
Additional Best Practices
- One logical change per commit: Each commit should represent a single logical change
- Build should pass: Every commit should leave the codebase in a working state
- Self-contained: Include all related changes (code, tests, docs) in one commit
- Reviewable size: Keep commits small enough to review effectively
- No merge commits: Use rebase instead of merge when updating branches
- Meaningful history: Write commits as if explaining changes to a future developer
Scope Examples
Common scopes based on project structure:
- Component names:
(header),(footer),(navbar) - Modules:
(auth),(user),(payment) - Layers:
(api),(db),(ui) - Features:
(search),(checkout),(dashboard)
These practices ensure a clean, searchable, and meaningful git history that helps with debugging, code reviews, and automated changelog generation.
Metadata
Metadata
Assignees
Labels
No labels