Git: Conventional Commits

Conventional Commits provide a standardised convention for writing commit messages, ensuring that the commit history is understandable and useful.

What are Conventional Commits?

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. The convention involves using a structured format for commit messages, making it easier to automate the release process, generate changelogs, and communicate changes clearly to your team.

Conventional Commits Format

A typical Conventional Commit message consists of a type, an optional scope, and a description. Optionally, it can also include a body and footer.

Format:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Conventional Commits Examples:

feat(auth): add login feature
fix(auth): resolve login issue
docs(readme): update installation instructions

Key Components of Conventional Commits

1. Structure: A commit message consists of a header, optional body, and optional footer.

• Header: Contains a type, an optional scope, and a subject.

<type>(<scope>): <subject>

• Body: Provides a detailed description of the change.
• Footer: Includes any breaking changes and issues closed by the commit.

2. Types: Indicate the nature of the change. Common types include:

• feat: A new feature.
• fix: A bug fix.
• docs: Documentation only changes.
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
• refactor: A code change that neither fixes a bug nor adds a feature.
• perf: A code change that improves performance.
• test: Adding missing tests or correcting existing tests.
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation.
• Scope: An optional part that provides additional contextual information. For example, fix(parser):.

3. Subject: A brief description of the change. It should be concise and written in the imperative mood (e.g., "change" not "changed" or "changes").

4. Body: Explains the what, why, and how of the change. This part is optional but recommended for complex commits.

5. Footer: Contains information about breaking changes and references to issues that are closed by the commit. This is also where you can mention breaking changes, using the BREAKING CHANGE: prefix.

Conventional Commits Benefits

• Clarity: Provides a clear understanding of the changes made in each commit.
• Automation: Facilitates automated generation of change logs, versioning, and releases.
• Consistency: Ensures a uniform structure for commit messages, making it easier for teams to collaborate and review changes.

Tools for Conventional Commits

Several tools and extensions can help you enforce Conventional Commits, automate changelog generation, and streamline the release process.
1. Commitizen
Commitizen is a tool that prompts you to fill out the necessary fields for a Conventional Commit message, ensuring consistency and adherence to the specification.

2. Commitlint
Commitlint checks if your commit messages meet the Conventional Commits standard. It can be integrated into your CI/CD pipeline to enforce commit message guidelines.

GUI Tools and Extensions for Conventional Commits

VSCode Extensions
1. Conventional Commits: This VSCode extension provides an easy way to generate Conventional Commits.

2. Commitizen VSCode Plugin: This plugin integrates Commitizen into VSCode, providing a guided commit process.

Conclusion

Adopting Conventional Commits in your workflow can significantly enhance your project's maintainability, clarity, and automation capabilities. This structured approach not only benefits individual developers but also fosters better collaboration and communication within teams.

References:
https://www.conventionalcommits.org/
https://commitizen-tools.github.io/commitizen/
https://commitlint.js.org/