66 lines
2.0 KiB
Markdown
66 lines
2.0 KiB
Markdown
# Git Commit Guidelines
|
|
|
|
We have very precise rules over how our git commit messages can be formatted. This leads to **more
|
|
readable messages** that are easy to follow when looking through the **project history**. But also,
|
|
we use the git commit messages to **generate the change log**.
|
|
|
|
## 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>
|
|
<BLANK LINE>
|
|
<body>
|
|
<BLANK LINE>
|
|
<footer>
|
|
```
|
|
|
|
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
|
|
to read on github as well as in various git tools.
|
|
|
|
## Type
|
|
Must be one of the following:
|
|
|
|
* **feat**: A new feature
|
|
* **fix**: A bug fix
|
|
* **docs**: Documentation only changes
|
|
* **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 or adds a feature
|
|
* **perf**: A code change that improves performance
|
|
* **test**: Adding missing tests
|
|
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
|
|
generation
|
|
|
|
## Scope
|
|
The scope should refer to a module in hyper that is being touched. Examples:
|
|
|
|
* client
|
|
* server
|
|
* http1
|
|
* http2
|
|
* ffi
|
|
* upgrade
|
|
* examples
|
|
|
|
## Subject
|
|
|
|
The subject contains succinct description of the change:
|
|
|
|
* use the imperative, present tense: "change" not "changed" nor "changes"
|
|
* don't capitalize first letter
|
|
* no dot (.) at the end
|
|
|
|
## Body
|
|
|
|
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
|
|
The body should include the motivation for the change and contrast this with previous behavior.
|
|
|
|
## Footer
|
|
|
|
The footer should contain any information about **Breaking Changes** and is also the place to
|
|
reference GitHub issues that this commit **Closes**.
|
|
|
|
The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`
|