ISA-Frontend/.github/commit-instructions.md

Commit Message Instructions (Conventional Commits)

Commit messages should follow the Conventional Commits specification. 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