# Mastering Git: How to Write Effective Conventional Commit Messages ## Commit Message Formats ```bash (): empty separator line empty separator line ``` ### Inital Commit ```bash chore: init ``` ### Types * API relevant changes * `feat` Commits, that adds or remove a new feature * `fix` Commits, that fixes a bug * `refactor` Commits, that rewrite/restructure your code, however does not change any API behaviour * `perf` Commits are special `refactor` commits, that improve performance * `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc) * `test` Commits, that add missing tests or correcting existing tests * `docs` Commits, that affect documentation only * `build` Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ... * `ops` Commits, that affect operational components like infrastructure, deployment, backup, recovery, ... * `chore` Miscellaneous commits e.g. modifying `.gitignore` ### Scopes The `scope` provides additional contextual information. * Is an **optional** part of the format * Allowed Scopes depends on the specific project * Don't use issue identifiers as scopes ### Breaking Changes Indicator Breaking changes should be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint` * Is an **optional** part of the format ### Description The `description` contains a concise description of the change. * Is a **mandatory** part of the format * Use the imperative, present tense: "change" not "changed" nor "changes" * Think of `This commit will...` or `This commit should...` * Don't capitalize the first letter * No dot (`.`) at the end ### Body The `body` should include the motivation for the change and contrast this with previous behavior. * Is an **optional** part of the format * Use the imperative, present tense: "change" not "changed" nor "changes" * This is the place to mention issue identifiers and their relations ### Footer The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to. * Is an **optional** part of the format * **optionally** reference an issue by its id. * **Breaking Changes** should start with the word `BREAKING CHANGES:` followed by space or two newlines. The rest of the commit message is then used for this. ## Examples ```bash feat: an amazing button ``` ```bash fix: prevent racing of requests ``` ```bash feat(api): send an email to the customer when a product is shipped ``` ```bash feat!: allow provided config object to extend other configs BREAKING CHANGE: `extends` key in config file is now used for extending other config files ``` ```bash docs: correct spelling of CHANGELOG ``` ```bash test: test case for amazing button. ``` ```bash chore!: drop support for Node 6 BREAKING CHANGE: use JavaScript features not available in Node 6. ``` ```bash perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog ``` ```bash build: update dependencies ``` ```bash style: remove empty line ```