* Make sure your github account is linked to your intel.com email address
## Commit Message Guidelines
### Introduction
The intention of the strict rules for the content and structure of the commit message is to make project history more readable.
Both Conventional Commits [specification](https://www.conventionalcommits.org/en/v1.0.0/) and Angular's [Commit Message Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#commit) inspired the rules outlined below
### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:
```
<type>(<scope>): <subject>
<BLANKLINE>
<body>
<BLANKLINE>
<footer>
```
The **type** is mandatory and the **scope** of the header is optional. Both **type** and **scope** should always be **lowercase**. Multiple values of **type** and **scope** are not allowed.
Provide a couple sentences of human-readable content in the **body** of the commit message. Focus on the purpose of the changes.
Metadata associated with commit should be included in the **footer** part. Currently, it is expected to contain certificate of origin ( _Signed-Off-By:_ ) and tracker reference ( _Resolves:_ / _Related-To:_ ).
Allowed values for the **scope** are listed at the end of the [lint.yml](https://github.com/intel/compute-runtime/blob/master/.github/lint.yml) and should be extended sparingly, with extra caution.
Allowed values for the **type** are
* build
* ci
* documentation
* feature
* fix
* performance
* refactor
* test
Use the following checklist to determine which **type** to use in your commit:
0. Revert of a prior commit is a special case - use the following commit message format:
1. Use **type** == **documentation** when your commit modifies _only_ the human readable documentation
* this is currently applicable to markdown files, including programming guide
2. Use **type** == **ci** when your commit modifies _only_ the files with metadata related to the way we test, but does not affect local build flow
3. Use **type** == **build** when your commit modifies the build flow, but does not modify the codebase of compute-runtime itself
* example: updating the header dependencies in third_party folder
4. Use **type** == **test** when your commit modifies _only_ the files in test folders (unit_test, etc.) and not the actual runtime code
5. Use **type** == **performance** when your commit is intended to improve observable performance without affecting functionality,
* when in doubt whether to use performance vs. fix as type, performance is usually a better fit
6. Use **type** == **fix** when your commit is intended to improve the functional behavior of the compute-runtime
* when in doubt whether to use fix vs. feature as type, consider whether the feature being modified is enabled by default and already available in a posted release. If it is, use type == fix, otherwise use type == feature
7. Use **type** == **feature** when your commit is intended to add new functionality,
* New functionality means meaningful changes in functional behavior that would be detected by a black-box test in deterministic manner
* For features not intended to be eventually enabled by default (e.g. debugability / logging improvements / code only enabled via debug keys) - use **scope** == **internal**
8. Use **type** == **refactor** for all other cases
Note: usage of tracker reference with the _Resolves:_ or _Related-To:_ notation is mandatory for **type** == **feature** or **scope** == **wa**, and optional for all other values.
