conventional-pre-commit
A pre-commit hook to check commit messages for
Conventional Commits formatting.
Works with Python >= 3.8.
Usage
Make sure pre-commit is installed.
Create a blank configuration file at the root of your repo, if needed:
touch .pre-commit-config.yaml
Add/update default_install_hook_types and add a new repo entry in your configuration file:
default_install_hook_types:
- pre-commit
- commit-msg
repos:
# - repo: ...
- repo: https://github.com/compilerla/conventional-pre-commit
rev: <git sha or tag>
hooks:
- id: conventional-pre-commit
stages: [commit-msg]
args: []
Install the pre-commit script:
pre-commit install --install-hooks
Make a (normal) commit ❌:
$ git commit -m "add a new feature"
[INFO] Initializing environment for ....
Conventional Commit......................................................Failed
- hook id: conventional-pre-commit
- duration: 0.07s
- exit code: 1
[Bad commit message] >> add a new feature
Your commit message does not follow Conventional Commits formatting
https://www.conventionalcommits.org/
And with the --verbose arg:
$ git commit -m "add a new feature"
[INFO] Initializing environment for ....
Conventional Commit......................................................Failed
- hook id: conventional-pre-commit
- duration: 0.07s
- exit code: 1
[Bad commit message] >> add a new feature
Your commit message does not follow Conventional Commits formatting
https://www.conventionalcommits.org/
Conventional Commit messages follow a pattern like:
type(scope): subject
extended body
Please correct the following errors:
- Expected value for type from: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test
Run:
git commit --edit --file=.git/COMMIT_EDITMSG
to edit the commit message and retry the commit.
Make a (conventional) commit ✔️:
$ git commit -m "feat: add a new feature"
[INFO] Initializing environment for ....
Conventional Commit......................................................Passed
- hook id: conventional-pre-commit
- duration: 0.05s
Install with pip
conventional-pre-commit can also be installed and used from the command line:
pip install conventional-pre-commit
Then run the command line script:
conventional-pre-commit [types] input
-
[types]is an optional list of Conventional Commit types to allow (e.g.feat fix chore) -
inputis a file containing the commit message to check:
conventional-pre-commit feat fix chore ci test .git/COMMIT_MSG
Or from a Python program:
from conventional_pre_commit.format import is_conventional
# prints True
print(is_conventional("feat: this is a conventional commit"))
# prints False
print(is_conventional("nope: this is not a conventional commit"))
# prints True
print(is_conventional("custom: this is a conventional commit", types=["custom"]))
Passing args
conventional-pre-commit supports a number of arguments to configure behavior:
$ conventional-pre-commit -h
usage: conventional-pre-commit [-h] [--no-color] [--force-scope] [--scopes SCOPES] [--strict] [--verbose] [types ...] input
Check a git commit message for Conventional Commits formatting.
positional arguments:
types Optional list of types to support
input A file containing a git commit message
options:
-h, --help show this help message and exit
--no-color Disable color in output.
--force-scope Force commit to have scope defined.
--scopes SCOPES List of scopes to support. Scopes should be separated by commas with no spaces (e.g. api,client).
--strict Force commit to strictly follow Conventional Commits formatting. Disallows fixup! and merge commits.
--verbose Print more verbose error output.
Supply arguments on the command-line, or via the pre-commit hooks.args property:
repos:
- repo: https://github.com/compilerla/conventional-pre-commit
rev: <git sha or tag>
hooks:
- id: conventional-pre-commit
stages: [commit-msg]
args: [--strict, --force-scope, feat, fix, chore, test, custom]
NOTE: when using as a pre-commit hook, input is supplied automatically (with the current commit's message).
Development
conventional-pre-commit comes with a VS Code devcontainer
configuration to provide a consistent development environment.
With the Remote - Containers extension enabled, open the folder containing this repository inside Visual Studio Code.
You should receive a prompt in the Visual Studio Code window; click Reopen in Container to run the development environment
inside the devcontainer.
If you do not receive a prompt, or when you feel like starting from a fresh environment:
Ctrl/Cmd+Shift+Pto bring up the command palette in Visual Studio Code- Type
Remote-Containersto filter the commands - Select
Rebuild and Reopen in Containerto completely rebuild the devcontainer - Select
Reopen in Containerto reopen the most recent devcontainer build
Versioning
Versioning generally follows Semantic Versioning.
Making a release
Releases to PyPI and GitHub are triggered by pushing a tag.
- Ensure all changes for the release are present in the
mainbranch - Tag with the new version:
git tag vX.Y.Zfor regular release,git tag vX.Y.Z-preNfor pre-release - Push the new version tag:
git push origin vX.Y.Z
License
Inspired by matthorgan's pre-commit-conventional-commits.
Metadata
Release files for conventional-pre-commit 4.4.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| conventional_pre_commit-4.4.0.tar.gz | 27.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| conventional_pre_commit-4.4.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 44.0 kB
Release files / conventional_pre_commit-4.4.0.tar.gz
| Download URL | conventional_pre_commit-4.4.0.tar.gz |
|---|---|
| Size | 27.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
5426bef9039a162c3203cc7de3624954dea7120af8dec6f878d8f1c83c58af7b
|
|
BLAKE2b-256 checksum How to use checksums |
eb6ac4c902f9526c026b8f5d59ac099028bea7acb2415d5f6603668e92dfa22c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Feb 18, 2026.
Transparency logRelease files / conventional_pre_commit-4.4.0-py3-none-any.whl
| Download URL | conventional_pre_commit-4.4.0-py3-none-any.whl |
|---|---|
| Size | 16.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5d266cb32a857344e1c4d87660c290cca1646d1ae480dcef6388e27bbc7f022f
|
|
BLAKE2b-256 checksum How to use checksums |
3f26affaaa8928f04729d0e69b33b4643a9713eaa270e9712892347f3c683ce5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Feb 18, 2026.
Transparency log