# Commit Message Instructions (Conventional Commits)

Commit messages should follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand changes, automate changelog generation, and trigger build/publish processes.

## Format

The commit message structure is as follows:

```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

---

### Components

1.  **Type**: Indicates the kind of change introduced by the commit. Must be one of the allowed types (see below).
2.  **Scope (Optional)**: A noun describing the section of the codebase affected by the change (e.g., `auth`, `ui`, `build`). Enclosed in parentheses.
3.  **Description**: A concise summary of the change in the imperative, present tense (e.g., "add login feature", not "added login feature" or "adds login feature"). Starts with a lowercase letter and should not end with a period. Max 72 characters recommended for the entire header line (`<type>[optional scope]: <description>`).
4.  **Body (Optional)**: A more detailed explanation of the changes. Use the imperative, present tense. Explain the _what_ and _why_ vs. _how_. Separate from the description by a blank line. Wrap lines at 72 characters.
5.  **Footer(s) (Optional)**: Contains additional metadata. Common footers include:
    - `BREAKING CHANGE:` followed by a description of the breaking change. A `!` can also be appended to the type/scope (`feat!:`) to indicate a breaking change.
    - Issue references (e.g., `Refs: #123`, `Closes: #456`). Separate from the body by a blank line.

---

### Allowed Types

- **feat**: A new feature for the user.
- **fix**: A bug fix for the user.
- **build**: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
- **chore**: Other changes that don't modify src or test files (e.g., updating dependencies, build tasks).
- **ci**: Changes to CI configuration files and scripts (e.g., Travis, Circle, BrowserStack, SauceLabs).
- **docs**: Documentation only changes.
- **perf**: A code change that improves performance.
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
- **test**: Adding missing tests or correcting existing tests.

---

### Examples

**Commit with description only:**

```
fix: correct minor typos in code
```

**Commit with scope:**

```
feat(lang): add polish language
```

**Commit with body and breaking change footer:**

```
refactor: drop support for Node 6

The new implementation relies on async/await and other features
introduced in Node 8+.

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```

**Commit with scope, body, and issue footer:**

```
docs(readme): improve installation instructions

Provide clearer steps for setting up the development environment.
Add links to prerequisite tools.

Closes: #12
```

**Commit with `!` for breaking change:**

```
feat(api)!: send an email to the customer when a product is shipped
```