|
| 1 | +## <a name="commit"></a> Commit Message Guidelines |
| 2 | + |
| 3 | +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**. For full contribution guidelines visit |
| 4 | +the [Contributors Guide](https://wiki.edgexfoundry.org/display/FA/Committing+Code+Guidelines#CommittingCodeGuidelines-Commits) on the EdgeX Wiki |
| 5 | + |
| 6 | +### Commit Message Format |
| 7 | +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**: |
| 8 | + |
| 9 | +``` |
| 10 | +<type>(<scope>): <subject> |
| 11 | +<BLANK LINE> |
| 12 | +<body> |
| 13 | +<BLANK LINE> |
| 14 | +<footer> |
| 15 | +``` |
| 16 | + |
| 17 | +The **header** with **type** is mandatory. The **scope** of the header is optional. This repository has no predefined scopes. A custom scope can be used for clarity if desired. |
| 18 | + |
| 19 | +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. |
| 20 | + |
| 21 | +The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any. |
| 22 | + |
| 23 | +Example 1: |
| 24 | +``` |
| 25 | +feat: add new device wizard |
| 26 | +``` |
| 27 | + |
| 28 | +Example 2: |
| 29 | +``` |
| 30 | +fix: correct default database port configuration |
| 31 | +
|
| 32 | +Previously configuration used to the wrong default database port. This commit fixes the default database port for Redis in the configuration. |
| 33 | +
|
| 34 | +Closes: #123 |
| 35 | +``` |
| 36 | + |
| 37 | +### Revert |
| 38 | +If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
| 39 | + |
| 40 | +### Type |
| 41 | +Must be one of the following: |
| 42 | + |
| 43 | +* **feat**: A new feature |
| 44 | +* **fix**: A bug fix |
| 45 | +* **docs**: Documentation only changes |
| 46 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc) |
| 47 | +* **refactor**: A code change that neither fixes a bug nor adds a feature |
| 48 | +* **perf**: A code change that improves performance |
| 49 | +* **test**: Adding missing tests or correcting existing tests |
| 50 | +* **build**: Changes that affect the CI/CD pipeline or build system or external dependencies (example scopes: travis, jenkins, makefile) |
| 51 | +* **ci**: Changes provided by DevOps for CI purposes. |
| 52 | +* **revert**: Reverts a previous commit. |
| 53 | + |
| 54 | +### Scope |
| 55 | +There are no predefined scopes for this repository. A custom scope can be provided for clarity. |
| 56 | + |
| 57 | +### Subject |
| 58 | +The subject contains a succinct description of the change: |
| 59 | + |
| 60 | +* use the imperative, present tense: "change" not "changed" nor "changes" |
| 61 | +* don't capitalize the first letter |
| 62 | +* no dot (.) at the end |
| 63 | + |
| 64 | +### Body |
| 65 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". |
| 66 | +The body should include the motivation for the change and contrast this with previous behavior. |
| 67 | + |
| 68 | +### Footer |
| 69 | +The footer should contain any information about **Breaking Changes** and is also the place to |
| 70 | +reference GitHub issues that this commit **Closes**. |
| 71 | + |
| 72 | +**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this. |
| 73 | + |
0 commit comments