cz-git keeps its configuration on a website and its own npm root private

The README is a row of links, and the install snippet ships npm's output

Most of the top-level document is navigation. Installation, Configure Template, Options, Recipes, FAQ, a CLI page and a Simplified Chinese version of the docs are each a single line ending in a link to cz-git.qbb.sh, and the only runnable text in the whole file is two npm transcripts. Both of those carry npm's own output lines inside the fence, so a copy and paste takes the package size line with it:

$ npm i -D cz-git
+ cz-git          (1.76 MB)
added 1 package in 0.552s

That is the entire picture of how the two packages differ, in bytes: 1.76 MB for the adapter, 1.32 MB for the CLI. Configuration keys, scopes for monorepos, the issue prefix and the AI option are all behind those links rather than in the repository's front page.

Two npm names for one project, with different jobs and different install scope

The two packages are not a library and a thin wrapper around it. cz-git is a Commitizen adapter: the term used for it is a replacement for the interactive plugin of the cz-cli command line tool, so it is installed as a development dependency and then invoked through Commitizen. czg is the standalone commit command, installed globally, which is why its install line is different:

$ npm i -g czg

Both are linked from npmjs.com/package/cz-git and npmjs.com/package/czg, and czg is also published to Homebrew as a formula named czg. The project ships a local alias for the CLI inside its own scripts, where the script named x simply calls czg, so contributors and users end up with the same binary name. Both paths require Node v12.20 or newer.

The repository root package is private, so the published code is in the workspace

The package.json at the root of the repository is named cz-git and carries version 1.14.0, but it is also marked private, so nothing is published from that file. The real code lives under packages/, with pnpm-workspace.yaml and pnpm-lock.yaml at the root, and the scripts address it with filters such as `@cz-git/*` for build and dev tasks. The toolchain is pinned in that same file: packageManager is [email protected]. Put next to the Node v12.20 floor stated in the README, that pairing is worth noticing, because the documented minimum and the pinned package manager are not the same claim. Bundling, tests and linting are all separate root configs: tsup.config.ts, vitest.config.ts and eslint.config.mjs.

cz-gitee sits in the keyword list and nowhere else

The keywords array in package.json lists commitizen-adapter, cli, cz-cli, cz-git, cz-gitee, cz-adapter, customizable and cz-customizable. cz-gitee is the only one of those that does not appear anywhere in the README, and no feature bullet, option page name or recipe is written for a Gitee host in what the repository documents. The package description also differs from the repository description: package.json says a better customizable and git support commitizen adapter, while the repository blurb leads with DX first and more engineered, lightweight, customizable, standard output format. Both are marketing strings about feel rather than mechanics, so the keyword list is the only machine-readable description of what the packages claim to be.

A plain install of the adapter runs simple-git-hooks on postinstall

The postinstall script is simple-git-hooks, so adding cz-git as a development dependency is not a read-only operation: npm runs a hook installer that writes into the git hooks directory of whatever repository you are standing in. That matters most on teams that already manage hooks through another tool, and the release machinery shows how much this project depends on hooks. The release chain is a run-s sequence of lint, test:run, release:bump and release:publish. The bump step runs bumpp with the recursive and all flags across the workspace and commits as build: :bookmark: publish v%s, which is one place the emoji support the project advertises shows up in its own history. The post-bump step then regenerates the schema, rebuilds the changelog and rebuilds the packages.

Conventional Commits output, emoji tokens, and commitlint in between

The output format is claimed to follow the Conventional Commits specification at version 1.0.0, and one feature bullet is support commit with emoji, which is what produces the :bookmark: style shortcodes rather than literal characters. Those two promises meet in the middle, where commitlint reads the message. A commitlint.config.mjs sits at the root of this repository, and the feature list says the tooling is built for commitlint projects to give relevant verification information to the command line, so the validation result is expected to arrive in the prompt rather than in a separate lint step. A separate recipe covers issue linking through issuePrefix, and another covers scopes for monorepo engineering, which is where a workspace with dozens of packages decides which scope name a change gets.

An .x-cmd directory sits at the root with no explanation anywhere

The root tree carries two editor or tool configuration directories, .vscode and .x-cmd, alongside .editorconfig, and neither of the two directories is mentioned in the README or in any of the linked section names. What is documented is more mundane: a scripts/ directory with a docs update step run through tsx, a schema generation step run through tsx, and three demo scripts that execute examples from the plugin-inquirer package, one each for a checkbox, an input and a list. The documentation site itself is built from docs/ and previewed through scripts named docs:dev and docs:preview, with netlify.toml holding the hosting configuration, and a zh/ path serving Simplified Chinese.

The prompt is a search and selection widget, not a set of flags

The first feature bullet is framed as convenience rather than capability: a friendly command line tool that supports search and selection, described as a way of reducing spelling errors, and put in the imperative just to be a lazy man. That single design choice explains the rest of the surface. Instead of typing a type and a scope correctly, the prompt lets you search for them, and the three example scripts named in the root scripts correspond to the three widget types the inquirer plugin supports: checkbox for multi-select, input for a single value and list for one choice. Option groups are split the same way on the documentation site, into show related settings and engineering related settings, with OpenAI generation of the commit message offered as a further choice in the same flow.

Editorial conclusion

cz-git is worth trying if your team already wants Conventional Commits output and wants the typing done by search and selection instead of memorized flags. Check three things first: whether your git hooks are managed by something else, since a plain install of the adapter runs simple-git-hooks on postinstall; whether the monorepo scopes recipe matches your package layout; and whether the emoji option is acceptable to your commitlint configuration. The MIT license is short and the maintenance cadence is slow but not dead, with v1.14.0 dated 2026-08-22 after a three month gap from v1.13.1.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Zhengqbbb/cz-git on GitHub