How I write Commits like a pro

Crafting effective commit messages is a hallmark of experienced developers. Embracing the Conventional Commits specification stands as a beacon for structuring commit messages. It’s not just a guideline; it’s a pathway to a clearer commit history that harmonizes with Semantic Versioning (SemVer).

What are Conventional Commits?

Conventional Commits offer a lightweight yet powerful framework for organizing commit messages. By categorizing changes into distinct types like features, fixes, and breaking changes, it sets a gold standard for clarity and consistency and aligns with Semantic Versioning (SemVer) by categorizing changes into features, fixes, and breaking changes.

The Anatomy of a Great Commit Message

When making commits, please use the conventional commit format, which typically follows the pattern of <type>: <description>.

A commit message should follow this structure:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

type: type of commit

scope: Short description of a section of the codebase enclosed in parenthesis followed by a colon and a space

description : Short description of the code changes

body: A longer description of the commit, providing additional context about the changes.
Must be placed one empty line after the description.

footer: Fixes issue #3 //example
The footer should only contain additional issue references about the changes.

Examples:

A commit I made to solve an issue.

feat(homepage): Add carousel feature to showcase testimonials

Implemented a carousel component on the homepage
Added client testimonials section for improved user engagement

Fixes #12

More examples:

• feat: Add new rating component

• fix: Resolve issue with city search feature

• docs: Update README with new contribution guidelines

Types of Commits

In addition to the classic fix and feat, we've got a whole buffet of commit types. It's like choosing toppings for your commit pizza:

- build: Changes related to build processes or tools.
- chore: Regular maintenance or administrative tasks.
- ci: Updates to the continuous integration setup.
- docs: Documentation-related changes.
- style: Changes that do not affect the code’s functionality (e.g., formatting).
- refactor: Code modifications without changing its behavior.
- perf: Performance improvements.
- test: Adding or modifying tests.

You can use these types to categorize your commits according to their nature. This helps maintain consistency in commit messages and aids in better organization of changes in the project history.

Footnote

For more information on Conventional Commits, visit Conventional Commits Specification.