Git commit messages plays an important role in the life of developers. If your git commit messages are clean and organized you can easily understand and refer to previous code changes using commit messages itself. It helps other teammates as well to visualize the evolution of the feature development or bug fixes step by step easily.
In this blog post, I will explain more about a tool called commitizen which can help your team to adopt to writing organized git commit messages with less effort.
What is Commitizen?
Commitizen is a tool designed for teams.
Its main purpose is to define a standard way of committing rules and communicating them using the CLI provided by commitizen.
The reasoning behind it is that it is easier to read, and enforces writing descriptive commits.
Besides that, having a convention on your commits makes it possible to parse them and use them for something else, like generating automatically the version or a changelog.
- Command-line utility to create commits with your rules. By Default, it uses Conventional commits rules for commit messages.
- Display information about your commit rules (commands: schema, example, info)
- Bump version automatically using semantic versioning based on the commits. It uses semantic versioning means it uses MAJOR.MINOR.PATCH format for versioning the releases.
|Increment||Description||Conventional commit map|
|MAJOR||Breaking changes introduced||
- Generate a changelog using Keep a changelog.
On macOS, it can be installed via homebrew:
brew install commitizen
On other operating systems, it can be installed via
sudo pip3 install -U Commitizen
Local Project Installation
pip install -U commitizen
Git Commit using Commitizen
After installing commitizen you can run
cz commit inside your git repository and it will show the following options.
➜ course-tracker git:(master) ✗ cz commit ? Select the type of change you are committing (Use arrow keys) » fix: A bug fix. Correlates with PATCH in SemVer feat: A new feature. Correlates with MINOR in SemVer 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 or correcting existing tests build: Changes that affect the build system or external dependencies (example scopes: pip, docker, npm) ci: Changes to our CI configuration files and scripts (example scopes: GitLabCI)
If you observe you can see 9 options that cover most of the activities in the development lifecycle starting from
- bug fixes
- code styling
- performance improvement
- unit/integration testing
- prepare build
- changes for CI pipelines
In this example, I will select
docs as I made few minor changes to my README file in my project. Also updated remaining steps like adding
subjectfor the changes in the commit.
is breaking change?in this example it's simple change.
➜ course-tracker git:(master) ✗ cz commit ? Select the type of change you are committing docs: Documentation only changes ? Scope. Could be anything specifying place of the commit change (users, db, poll): project-setup ? Subject. Concise description of the changes. Imperative, lower case and no final dot: Update Setup Instructions ? Body. Motivation for the change and contrast this with previous behavior: ? Is this a BREAKING CHANGE? Correlates with MAJOR in SemVer No ? Footer. Information about Breaking Changes and reference issues that this commit closes: docs(project-setup): Update Setup Instructions 1 file changed, 1 insertion(+) Commit successful!
Now, our git log will look like this below.
commit 22d248315af3176952d56dd0cb712667900a37ba (HEAD -> master) Author: Vishnu Chilamakuru Date: Tue Jun 1 14:20:23 2021 +0530 docs(project-setup): Update Setup Instructions
My git commit message is properly organized now for corresponding subjects and use-cases and it is easy to refer to my project git timeline to refer to features, fixes, docs, etc...Below is the sample timeline of the repository using commitizen.
Hope you like the article.
Thank you for reading
Hope you find these resources useful. If you like what you read and want to see more about system design, microservices, and other technology-related stuff... You can follow me on