How I write Commits like a pro
write commit messages like an experienced developer
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:
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.