Master Commit Message Standards with Conventional Commits, Commitizen, and Husky
This guide explains why consistent commit messages matter, introduces the Conventional Commits specification, and provides step‑by‑step instructions for setting up Commitizen, Husky, and Commitlint to enforce a clear, SemVer‑compatible commit workflow across a project.
Git is the most popular version control tool, and well‑written commit messages greatly improve code maintenance efficiency. However, without constraints, commit messages are often inconsistent and hard to read, so introducing a commit‑message convention is essential.
Which convention?
The widely adopted solution is the Conventional Commits specification, inspired by the Angular commit guidelines. It provides a lightweight, message‑based convention that aligns with SemVer and makes automated tooling easier.
<type>[optional scope]: <description>
[optional body]
[optional footer]Quick Start
1. Install commitizen & cz-conventional-changelog globally
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrcAfter installation you can use git cz instead of git commit.
2. Add commitlint & husky to the project
npm i -D husky @commitlint/config-conventional @commitlint/cliConfigure husky in package.json to run commitlint on the commit‑msg hook.
{
"husky": {
"hooks": {
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
}3. Create commitlint.config.js
# In the same path as package.json
echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js4. Use the interactive git cz flow
1. Select the type of change (feat, fix, docs, style, build, refactor, revert, …)
2. Specify the scope (project/module)
3. Write a short imperative description
4. (Optional) Write a longer body
5. Indicate any breaking changes
6. Reference affected issuesThe resulting commit message follows the pattern:
<type>(<scope>): <subject>
<body>
<footer>Commit Message Rules Used in rrd‑fe
1. type
Required. Main types: feat (new feature) and fix (bug fix). Additional types: docs, style, build, refactor, revert. Others are currently unused.
# Main types
feat: add new feature
fix: fix a bug
# Additional types
docs: documentation only changes
style: formatting changes that do not affect code meaning
build: changes to build tools or external dependencies
refactor: code refactoring
revert: revert a previous commit2. scope
Required. Describes the affected part, formatted as project/module, e.g., node-pc/common or rrd-h5/activity. If a commit touches multiple modules, split it into separate commits.
3. body
Provides a detailed description of the previous state and the motivation for the change. Required for significant changes.
4. break changes
Indicates whether the change introduces breaking API modifications; must be specified for version upgrades, removed parameters, etc.
5. affect issues
Links the commit to issue identifiers (e.g., JIRA IDs) when integrated with Jira and GitLab.
Example
Full commit message example:
Corresponding git log output:
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.