This project follows the principles of "CONVENTIONAL COMMITS"
Please make sure to go check the description before commiting.
Below a summary of the principles
OBF - Original Black Flag) Blog<type>[optional scope]: <description>
[optional body]
[optional footer]
-
Type: Describes the nature of the commit. Common types include:
- feat: A new feature
- fix: A bug fix
- docs: Documentation changes
- style: Code style/formatting changes
- refactor: Code refactoring without changing its behavior
- test: Adding or modifying tests
- chore: Changes related to build processes, tooling, etc.
- perf: Performance improvements
-
Optional Scope: Indicates the section of the codebase affected by the commit.
-
Description: Brief summary of the changes. Use imperative language ("Add feature" instead of "Added feature").
-
Optional Body: Additional details explaining the commit, if needed. This section can provide more context about the changes made.
-
Optional Footer: Includes metadata or references, such as issue tracker IDs or breaking change notices.
| New Feature | `feat(api): Add endpoint for user authentication` |
| Big Fix | `fix(ui): Resolve issue with button alignment` |
| Documentation Change | `docs(readme): Update installation instructions` |
| Code Style | `style(format): Apply consistent code formatting` |
| Refactor | `refactor(api): Restructure data models for improved readability` |
| Test | `test(auth): Add unit tests for authentication logic` |
| Chore | `chore(build): Update dependencies for security patches` |
| Performance Improvement | `perf(api): Optimize database queries for faster response` |
-
Clarity and Readability: Offers a consistent and standardized format for commit messages, making it easier to understand changes.
-
Automated Release Notes: Tools can automatically generate release notes and version bumps based on commit messages following this convention.
-
Facilitates Collaboration: Enhances communication among team members by providing clear information about changes made.