Structure of a conventional commit
- First line starting with the type of commit, followed by a colon (
:), followed by a message summarising the commit. - The type can optionally be supplemented by a scope in brackets to specify the component or feature that has been modified.
- Optionally, one or more additional paragraphs describing the commit in more detail can be added after a blank line. Markdown syntax can be used.
- Finally, a last line (separated from the previous ones by a blank line) must contain a reference to the ticket to which the commit is linked. The reference takes the following form:
Refs: #XXX, orFix: #XXXto automatically close the ticket when merging into the destination branch.
Example of a conventional commit
Example of a complete commit log:
fix: repair the link to the GPL licence in the footer of private pages
by replacing it with a simple link to the official gnu.org website
Fix: #5328
List of commit types
Convention used in SPIP.
| Type | Meaning |
|---|---|
| build | Modifies a program compilation script or modifies external dependencies. Also indicates a version upgrade. |
| change | Modifies the implementation of a feature — may modify function signatures (≠ refactor) |
| chore | Background work that does not alter the code (release a version, regenerate compiled code) |
| ci | Related to continuous integration |
| deprecate | Deprecate (without removing) a feature |
| docs | Related to documentation (docs, readme, changelog) |
| feat | Adds a feature |
| fix | Fixes a problem |
| i18n | Related to translations and language strings |
| perf | Improves algorithm or programme performance |
| refactor | Rewrites code without changing its implementation |
| remove | Removes code or functionality (previously deprecated) |
| revert | Reverses a previous change (commit) |
| security | Related to security |
| style | Related to code writing rules (Coding Standard) |
| test | Related to software testing |
Further reading
See the websitewww.conventionnalecommits.