-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: convential commits spec #1405
Conversation
WalkthroughThe Changes
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
convential_commits.md (1)
1-10
: Consider enhancing the rationale section with examples.While the guidelines are clear, adding examples would make them more actionable:
- Show how semantic versioning ties into conventional commits (e.g.,
feat!: breaking change in API
)- Include examples of good PR titles that follow the convention
- Semantic versioning is **mandatory** for Pull Requests, particularly the use of `!` for breaking changes. +- Semantic versioning is **mandatory** for Pull Requests, particularly the use of `!` for breaking changes. For example: + - `feat(api)!: remove deprecated endpoints` + - `fix: resolve memory leak in worker pool` + - `docs: update installation guide`
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
convential_commits.md
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (9)
- GitHub Check: startup-functional-test (3.12)
- GitHub Check: startup-docker-compose-test
- GitHub Check: migrations-check (3.12)
- GitHub Check: enterprise-startup-functional-test (3.12)
- GitHub Check: functional-tests (3.12, chromium)
- GitHub Check: enterprise-startup-docker-compose-test
- GitHub Check: enterprise-functional-tests (3.12, chromium)
- GitHub Check: Analyze (python)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
convential_commits.md (1)
1-23
: Well-structured conventional commits documentation!The document provides clear guidelines and rationale for adopting conventional commits. The balance between mandatory and recommended practices is pragmatic and should help with adoption.
## Convention | ||
|
||
- Use lowercase for all commit messages. | ||
- Include a scope when relevant. For example, use `feat(lib)` when adding a new framework or library. | ||
- The following commit types are supported: | ||
- `fix`: Bug fixes | ||
- `feat`: New features | ||
- `chore`: Maintenance tasks or changes that don't affect production code | ||
- `refactor`: Code changes that neither fix bugs nor add features | ||
- `docs`: Documentation updates or improvements | ||
- `test`: Adding or updating tests | ||
- `ci`: Changes to the CI configuration or scripts | ||
- `build`: Changes that affect the build system or external dependencies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Enhance convention details with additional guidelines.
Consider adding these important aspects of conventional commits:
- Guidelines for commit message body and footer
- Breaking change footer format (
BREAKING CHANGE: description
) - Multi-line commit message format
- Common scope examples for your project
- Include a scope when relevant. For example, use `feat(lib)` when adding a new framework or library.
+- Include a scope when relevant. Common scopes include:
+ - `api`: API-related changes
+ - `ui`: User interface changes
+ - `db`: Database changes
+ - `lib`: Library or dependency changes
+
+- Commit message format:
+ ```
+ <type>[optional scope]: <description>
+
+ [optional body]
+
+ [optional footer(s)]
+ ```
+
+- For breaking changes, include a footer:
+ ```
+ BREAKING CHANGE: <description>
+ ```
- The following commit types are supported:
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
## Convention | |
- Use lowercase for all commit messages. | |
- Include a scope when relevant. For example, use `feat(lib)` when adding a new framework or library. | |
- The following commit types are supported: | |
- `fix`: Bug fixes | |
- `feat`: New features | |
- `chore`: Maintenance tasks or changes that don't affect production code | |
- `refactor`: Code changes that neither fix bugs nor add features | |
- `docs`: Documentation updates or improvements | |
- `test`: Adding or updating tests | |
- `ci`: Changes to the CI configuration or scripts | |
- `build`: Changes that affect the build system or external dependencies | |
## Convention | |
- Use lowercase for all commit messages. | |
- Include a scope when relevant. Common scopes include: | |
- `api`: API-related changes | |
- `ui`: User interface changes | |
- `db`: Database changes | |
- `lib`: Library or dependency changes | |
- Commit message format: |
will cover and fix #1334
Summary by CodeRabbit
conventional_commits.md
with comprehensive guidelines for commit message standards