43 lines
1.6 KiB
Markdown
43 lines
1.6 KiB
Markdown
# Contribution Guidelines
|
|
|
|
To ensure a consistent and readable git history, this project adheres to the [Conventional Commits](https://www.conventionalcommits.org/) specification.
|
|
|
|
## Commit Message Format
|
|
|
|
Each commit message consists of a **header**, a **body**, and a **footer**.
|
|
|
|
```
|
|
<type>[optional scope]: <description>
|
|
|
|
[optional body]
|
|
|
|
[optional footer]
|
|
```
|
|
|
|
### Type
|
|
|
|
The type must be one of the following:
|
|
|
|
* **feat**: A new feature for the user.
|
|
* **fix**: A bug fix for the user.
|
|
* **docs**: Changes to the documentation.
|
|
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
|
|
* **refactor**: A code change that neither fixes a bug nor adds a feature.
|
|
* **perf**: A code change that improves performance.
|
|
* **test**: Adding missing tests or correcting existing tests.
|
|
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation.
|
|
* **build**: Changes that affect the build system or external dependencies.
|
|
* **ci**: Changes to our CI configuration files and scripts.
|
|
|
|
### Description
|
|
|
|
The description is a short summary of the code changes. Use the imperative, present tense: "change" not "changed" nor "changes".
|
|
|
|
### Breaking Changes
|
|
|
|
A commit that has a footer beginning with `BREAKING CHANGE:` introduces a breaking API change. A BREAKING CHANGE can be part of any type of commit.
|
|
|
|
---
|
|
|
|
*This document provides a summary. For more details, please refer to the [official Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).*
|