Convert Figma logo to code with AI

commitizen logocz-cli

The commitizen command line utility. #BlackLivesMatter

16,701
547
16,701
190

Top Related Projects

📓 Lint commit messages

32,324

Git hooks made easy 🐶 woof!

:package::rocket: Fully automated version management and package publishing

35,643

:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.

Generate changelogs and release notes from a project's commit messages and metadata.

Quick Overview

Commitizen (cz-cli) is a command-line tool that helps standardize commit messages across projects. It provides an interactive prompt to guide developers in creating consistent and well-formatted commit messages, following conventional commit standards.

Pros

  • Enforces consistent commit message format across teams and projects
  • Simplifies the process of writing meaningful commit messages
  • Integrates well with semantic versioning and automated changelog generation
  • Customizable to fit specific project needs or commit conventions

Cons

  • Requires initial setup and configuration
  • May have a learning curve for team members not familiar with conventional commits
  • Can be perceived as restrictive by some developers who prefer free-form commit messages
  • Dependency on external tools may complicate the development workflow for some teams

Code Examples

  1. Basic usage with npm:
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
  1. Using Commitizen in a project:
# Initialize Commitizen in your project
commitizen init cz-conventional-changelog --save-dev --save-exact
  1. Committing changes with Commitizen:
git add .
git cz
# Follow the interactive prompts to create your commit message

Getting Started

To get started with Commitizen:

  1. Install Commitizen globally:

    npm install -g commitizen
    
  2. Install a commit message adapter (e.g., cz-conventional-changelog):

    npm install -g cz-conventional-changelog
    
  3. Create a .czrc file in your home directory:

    echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
    
  4. In your project, use git cz instead of git commit when committing changes.

  5. Follow the interactive prompts to create your commit message.

For project-specific configuration, initialize Commitizen in your project:

commitizen init cz-conventional-changelog --save-dev --save-exact

This will add the necessary dependencies and update your package.json file.

Competitor Comparisons

📓 Lint commit messages

Pros of commitlint

  • Focuses on enforcing commit message conventions rather than guiding the commit process
  • Highly configurable with various rules and plugins
  • Can be integrated into CI/CD pipelines for automated checks

Cons of commitlint

  • Requires more setup and configuration compared to cz-cli
  • May be less user-friendly for developers new to conventional commits
  • Doesn't provide an interactive commit message creation process

Code Comparison

cz-cli:

// Example usage in package.json
"scripts": {
  "commit": "cz"
}

commitlint:

// Example commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional']
};

Summary

cz-cli (Commitizen) is an interactive tool that guides developers through creating conventional commit messages, making it easier for teams to adopt standardized practices. It's more user-friendly and requires less initial setup.

commitlint, on the other hand, focuses on enforcing commit message conventions through linting. It's highly configurable and can be integrated into CI/CD pipelines, but may have a steeper learning curve for teams new to conventional commits.

Both tools aim to improve commit message consistency, but they approach the problem from different angles. cz-cli assists in creating commits, while commitlint validates them. Teams may choose one or use both together for a comprehensive solution.

32,324

Git hooks made easy 🐶 woof!

Pros of husky

  • Easier to set up and configure, with minimal changes to package.json
  • Supports a wider range of Git hooks, not just commit-related ones
  • Can be used for various tasks beyond commit message formatting

Cons of husky

  • Doesn't provide a standardized commit message format out of the box
  • Requires additional tools or custom scripts for commit message formatting
  • Less focused on commit message conventions, more general-purpose

Code comparison

husky configuration in package.json:

{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}

cz-cli usage:

git cz

Summary

husky is a more versatile tool for managing Git hooks, allowing developers to automate various tasks in their development workflow. It's easier to set up but requires additional configuration for commit message formatting. cz-cli, on the other hand, is specifically designed for standardizing commit messages and provides a more guided experience for creating conventional commits. The choice between the two depends on whether you need a general-purpose Git hook manager or a specialized tool for commit message formatting.

:package::rocket: Fully automated version management and package publishing

Pros of semantic-release

  • Fully automated version management and package publishing
  • Generates changelogs automatically based on commit messages
  • Integrates well with CI/CD pipelines for seamless releases

Cons of semantic-release

  • Requires strict adherence to conventional commit format
  • Less interactive and user-friendly for developers unfamiliar with the system
  • May require more initial setup and configuration

Code Comparison

semantic-release configuration (.releaserc.json):

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/npm",
    "@semantic-release/github"
  ]
}

cz-cli usage:

npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
git cz

Summary

semantic-release offers a more automated approach to version management and releases, while cz-cli focuses on helping developers write standardized commit messages. semantic-release is better suited for projects with established CI/CD pipelines and teams comfortable with conventional commits. cz-cli provides a more interactive experience and can be a gentler introduction to standardized commit practices. Both tools can be used together in a workflow, with cz-cli assisting in creating commits that semantic-release can then interpret for automated releases.

35,643

:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.

Pros of Lerna

  • Manages multiple packages within a single repository (monorepo)
  • Automates versioning and publishing of packages
  • Optimizes dependency management across packages

Cons of Lerna

  • Steeper learning curve for complex monorepo setups
  • Can be overkill for smaller projects or single-package repositories
  • Less focus on commit message standardization

Code Comparison

Lerna:

{
  "packages": ["packages/*"],
  "version": "independent",
  "command": {
    "publish": {
      "conventionalCommits": true
    }
  }
}

cz-cli:

{
  "path": "cz-conventional-changelog"
}

Key Differences

  • Lerna focuses on monorepo management and package publishing
  • cz-cli specializes in standardizing commit messages
  • Lerna has broader project management features
  • cz-cli is more lightweight and focused on a single task

Use Cases

  • Use Lerna for managing complex projects with multiple packages
  • Choose cz-cli for enforcing consistent commit messages across any project

Community and Ecosystem

  • Lerna has a larger ecosystem of plugins and integrations
  • cz-cli is more specialized but widely adopted for commit standardization

Learning Curve

  • Lerna requires more initial setup and configuration
  • cz-cli is simpler to integrate and start using quickly

Generate changelogs and release notes from a project's commit messages and metadata.

Pros of conventional-changelog

  • More comprehensive toolset for generating changelogs from Git metadata
  • Supports multiple preset configurations out-of-the-box
  • Offers greater flexibility in customizing changelog output

Cons of conventional-changelog

  • Steeper learning curve for initial setup and configuration
  • Requires more manual intervention for generating changelogs
  • Less interactive user experience compared to cz-cli

Code Comparison

conventional-changelog:

const conventionalChangelog = require('conventional-changelog');

conventionalChangelog({
  preset: 'angular',
  releaseCount: 0
}).pipe(process.stdout);

cz-cli:

const { prompt } = require('cz-cli');

prompt({
  type: 'list',
  name: 'type',
  message: 'Select the type of change:',
  choices: ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']
});

conventional-changelog focuses on generating changelogs programmatically, while cz-cli provides an interactive command-line interface for creating standardized commit messages. conventional-changelog offers more advanced features for changelog generation, but cz-cli excels in guiding developers through the commit process with a user-friendly prompt system.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Commitizen for contributors

When you commit with Commitizen, you'll be prompted to fill out any required commit fields at commit time. No more waiting until later for a git commit hook to run and reject your commit (though that can still be helpful). No more digging through CONTRIBUTING.md to find what the preferred format is. Get instant feedback on your commit message formatting and be prompted for required fields.

Backers on Open Collective Sponsors on Open Collective travis.ci Azure Build Status codecov.io npm monthly downloads current version semantic-release commitizen on stackoverflow

Installing the command line tool

Commitizen is currently tested against Node.js 12, 14, & 16, although it may work in older versions of Node.js. You should also have npm 6 or greater.

Installation is as simple as running the following command (if you see EACCES error, reading fixing npm permissions may help):

npm install -g commitizen

Using the command line tool

If your repo is Commitizen friendly:

Simply use git cz or just cz instead of git commit when committing. You can also use git-cz, which is an alias for cz.

Alternatively, if you are using npm 5.2+ you can use npx instead of installing globally:

npx cz

or as an npm script:

  ...
  "scripts": {
    "commit": "cz"
  }

When you're working in a Commitizen-friendly repository, you'll be prompted to fill in any required fields, and your commit messages will be formatted according to the standards defined by project maintainers.

Add and commit with Commitizen

If your repo is NOT Commitizen friendly:

If you're not working in a Commitizen-friendly repository, then git cz will work just the same as git commit, but npx cz will use the streamich/git-cz adapter. To fix this, you need to first make your repo Commitizen friendly

Making your repo Commitizen friendly

For this example, we'll be setting up our repo to use AngularJS's commit message convention, also known as conventional-changelog.

First, install the Commitizen CLI tools:

npm install commitizen -g

Next, initialize your project to use the cz-conventional-changelog adapter by typing:

# npm
commitizen init cz-conventional-changelog --save-dev --save-exact

# yarn
commitizen init cz-conventional-changelog --yarn --dev --exact

# pnpm
commitizen init cz-conventional-changelog --pnpm --save-dev --save-exact

Note that if you want to force install over the top of an old adapter, you can apply the --force argument. For more information on this, just run commitizen help.

The above command does three things for you:

  1. Installs the cz-conventional-changelog adapter npm module
  2. Saves it to package.json's dependencies or devDependencies
  3. Adds the config.commitizen key to the root of your package.json file as shown here:
...
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }

Alternatively, Commitizen configs may be added to a .czrc file:

{
  "path": "cz-conventional-changelog"
}

This just tells Commitizen which adapter we actually want our contributors to use when they try to commit to this repo.

commitizen.path is resolved via require.resolve and supports:

  • npm modules
  • directories relative to process.cwd() containing an index.js file
  • file base names relative to process.cwd() with .js extension
  • full relative file names
  • absolute paths

Please note that in the previous version of Commitizen we used czConfig. czConfig has been deprecated, and you should migrate to the new format before Commitizen 3.0.0.

Optional: Install and run Commitizen locally

Installing and running Commitizen locally allows you to make sure that developers are running the exact same version of Commitizen on every machine.

Install Commitizen with npm install --save-dev commitizen.

On npm 5.2+ you can use npx to initialize the conventional changelog adapter:

npx commitizen init cz-conventional-changelog --save-dev --save-exact

For previous versions of npm (< 5.2) you can execute ./node_modules/.bin/commitizen or ./node_modules/.bin/cz in order to actually use the commands.

You can then initialize the conventional changelog adapter using: ./node_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact

And you can then add some nice npm scripts in your package.json file pointing to the local version of Commitizen:

  ...
  "scripts": {
    "commit": "cz"
  }

This will be more convenient for your users because then if they want to do a commit, all they need to do is run npm run commit and they will get the prompts needed to start a commit!

NOTE: If you are using precommit hooks thanks to something like husky, you will need to name your script something other than "commit" (e.g. "cm": "cz"). The reason is because npm scripts has a "feature" where it automatically runs scripts with the name prexxx where xxx is the name of another script. In essence, npm and husky will run "precommit" scripts twice if you name the script "commit", and the workaround is to prevent the npm-triggered precommit script.

Optional: Running Commitizen on git commit

This example shows how to incorporate Commitizen into the existing git commit workflow by using git hooks and the --hook command-line option. This is useful for project maintainers who wish to ensure the proper commit format is enforced on contributions from those unfamiliar with Commitizen.

Once either of these methods is implemented, users running git commit will be presented with an interactive Commitizen session that helps them write useful commit messages.

NOTE: This example assumes that the project has been set up to use Commitizen locally.

Traditional git hooks

Update .git/hooks/prepare-commit-msg with the following code:

#!/bin/bash
exec < /dev/tty && node_modules/.bin/cz --hook || true
Husky

For husky users, add the following configuration to the project's package.json file:

"husky": {
  "hooks": {
    "prepare-commit-msg": "exec < /dev/tty && npx cz --hook || true"
  }
}

Why exec < /dev/tty? By default, git hooks are not interactive. This command allows the user to use their terminal to interact with Commitizen during the hook.

Congratulations! Your repo is Commitizen friendly. Time to flaunt it!

Add the "Commitizen friendly" badge to your README using the following markdown:

[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)

Your badge will look like this:

Commitizen friendly

It may also make sense to change your README.md or CONTRIBUTING.md files to include or link to the Commitizen project so that your new contributors may learn more about installing and using Commitizen.

Conventional commit messages as a global utility

Install commitizen globally, if you have not already.

npm install -g commitizen

Install your preferred commitizen adapter globally (for example cz-conventional-changelog).

npm install -g cz-conventional-changelog

Create a .czrc file in your home directory, with path referring to the preferred, globally-installed, commitizen adapter

echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

You are all set! Now cd into any git repository and use git cz instead of git commit, and you will find the commitizen prompt.

Pro tip: You can use all the git commit options with git cz. For example: git cz -a.

If your repository is a Node.js project, making it Commitizen friendly is super easy.

If your repository is already Commitizen friendly, the local commitizen adapter will be used, instead of globally installed one.

Commitizen for multi-repo projects

As a project maintainer of many projects, you may want to standardize on a single commit message format for all of them. You can create your own node module which acts as a front-end for Commitizen.

1. Create your own entry point script

// my-cli.js

#!/usr/bin/env node
"use strict";

const path = require('path');
const bootstrap = require('commitizen/dist/cli/git-cz').bootstrap;

bootstrap({
  cliPath: path.join(__dirname, '../../node_modules/commitizen'),
  // this is new
  config: {
    "path": "cz-conventional-changelog"
  }
});

2. Add the script to your package.json file

// package.json

{
  "name": "company-commit",
  "bin": "./my-cli.js",
  "dependencies": {
    "commitizen": "^2.7.6",
    "cz-conventional-changelog": "^1.1.5"
  }
}

3. Publish it to npm and use it!

npm install --save-dev company-commit

./node_modules/.bin/company-commit

Adapters

We know that every project and build process has different requirements, so we've tried to keep Commitizen open for extension. You can do this by choosing from any of the pre-built adapters or even by building your own. Here are some of the great adapters available to you:

To create an adapter, just fork one of these great adapters and modify it to suit your needs. We pass you an instance of Inquirer.js, but you can capture input using whatever means necessary. Just call the commit callback with a string and we'll be happy. Publish it to npm, and you'll be all set!

Retrying failed commits

As of version 2.7.1, you may attempt to retry the last commit using the git cz --retry command. This can be helpful when you have tests set up to run via a git precommit hook. In this scenario, you may have attempted a Commitizen commit, painstakingly filled out all of the commitizen fields, but your tests fail. In previous Commitizen versions, after fixing your tests, you would be forced to fill out all of the fields again. Enter the retry command. Commitizen will retry the last commit that you attempted in this repo without you needing to fill out the fields again.

Please note that the retry cache may be cleared when upgrading Commitizen versions, upgrading adapters, or if you delete the commitizen.json file in your home or temp directory. Additionally, the commit cache uses the filesystem path of the repo, so if you move a repo or change its path, you will not be able to retry a commit. This is an edge case but might be confusing if you have scenarios where you are moving folders that contain repos.

It is important to note that if you are running cz from an npm script (let's say it is called commit) you will need to do one of the following:

  • Pass -- --retry as an argument for your script. i.e: npm run commit -- --retry
  • Use npx to find and call the cz executable directly. i.e: npx cz --retry

Note that the last two options do not require you to pass -- before the args but the first does.

Commitizen for project maintainers

As a project maintainer, making your repo Commitizen friendly allows you to select pre-existing commit message conventions or to create your own custom commit message convention. When a contributor to your repo uses Commitizen, they will be prompted for the correct fields at commit time.

Go further

Commitizen is great on its own, but it shines when you use it with some other amazing open source tools. Kent C. Dodds shows you how to accomplish this in his Egghead.io series, How to Write an Open Source JavaScript Library. Many of the concepts can be applied to non-JavaScript projects as well.

Philosophy

About Commitizen

Commitizen is an open source project that helps contributors be good open source citizens. It accomplishes this by prompting them to follow commit message conventions at commit time. It also empowers project maintainers to create or use predefined commit message conventions in their repos to better communicate their expectations to potential contributors.

Commitizen or Commit Hooks

Both! Commitizen is not meant to be a replacement for git commit hooks. Rather, it is meant to work side-by-side with them to ensure a consistent and positive experience for your contributors. Commitizen treats the commit command as a declarative action. The contributor is declaring that they wish to contribute to your project. It is up to you as the maintainer to define what rules they should be following.

We accomplish this by letting you define which adapter you'd like to use in your project. Adapters just allow multiple projects to share the same commit message conventions. A good example of an adapter is the cz-conventional-changelog adapter.

Related projects

Authors and Contributors

@JimTheDev (Jim Cummins, author) @kentcdodds @accraze @kytwb @Den-dp

Special thanks to @stevelacy, whose gulp-git project makes commitizen possible.

Contributors

This project exists thanks to all the people who contribute. [Contribute].

Backers

Thank you to all our backers! 🙏 [Become a backer]

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

NPM DownloadsLast 30 Days