Skip to content
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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jan 22, 2025
Merged

docs: convential commits spec #1405

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions convential_commits.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
## Why

Based on the established documentation around [Conventional Commits](https://www.conventionalcommits.org) and the recommendations made in [#1334](https://github.com/intuitem/ciso-assistant-community/issues/1334), we have decided to adopt this principle using the following guidelines:

- Since v2, we have exclusively used squash merges, which has been beneficial so far. Therefore, we will continue to use this as the foundation for our workflow.
- Semantic versioning is **mandatory** for Pull Requests, particularly the use of `!` for breaking changes.
- Semantic commit messages are **recommended** for individual commits, as they will be included in the PR description after a squash merge.
- Renaming PR titles is significantly easier than reworking commits. While we encourage all contributors to adhere to the convention, reviewers can make necessary adjustments as needed.
- Reviewers must ensure consistency with the convention during the merge process.

## 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
Comment on lines +11 to +23
Copy link

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:

  1. Guidelines for commit message body and footer
  2. Breaking change footer format (BREAKING CHANGE: description)
  3. Multi-line commit message format
  4. 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.

Suggested change
## 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:

Loading