commit-msg
A lightweight golang implementation of git commit-msg hook.
Zero dependency, almost. ( homedir
with only ONE file is the ONLY dependency, no indirect dependencies. )
English | 中文
Install
Just put the executable binary into the hook directory of your project which using git as VCS.
Assuming the project root is /
, the hook directory should be /.git/hooks/
. Please make sure the binary is named as commit-msg
or commit-msg.exe
(win) , and the executable permission is granted.
If you can't find the hook directory, make sure the hidden directories are shown.
After installation, git will call it automatically to validate commit message, no manual calls are required.
From pre-built binary
You can download the latest pre-built binary from here . However, only win64 binaries are available.
Build and install from source code
For platforms other than win64, please setup the go environment and build it yourself.
Sorry for the poor instructions.
Configuration
The configuration file can be placed in two places:
- global config:
$HOME/.commit-msg.json
- project config:
project/.git/hooks/.commit-msg.json
Both configuration files can be set with neither or both, or you can choose to have only one of them. The program will try to load the global configuration first, then the project configuration, and the items set in both profiles will be subject to the project configuration.
The default commit-message format:
<type>(<scope>): <subject>
// empty line
<body>
// empty line
<footer>
Example:
feat(model): some changes to model layer
* change 1
* change 2
other notes
BREAKING CHANGE: some change break the compatibility
the way to migrate:
...
The following configuration items are supported.
lang
: prompt language. Currently only the built-in en
and zh
are supported, later on we will support adding custom language.
scopeRequired
: if true, (<scope>)
will be required.
scopes
: a list of strings, if not null or empty, then scope
must take a value from the list. This setting takes effect only when scope
is non-empty, and is independent of scopeRequired
.
types
and denyTypes
: both are string lists; keywords from types lists will be added to the default keyword list; keywords from denyTypes will be removed (if any). If a keyword appears in both lists, denyTypes prevails, since the keyword list add types
first and remove denyTypes
later.
The default type keyword list is:
feat
: new features
fix
: bug fixes
docs
: documents
style
: the style of the code, modifications that do not affect the running logic
refactor
: refactoring (logical changes neither new features nor to fix errors)
perf
: performance-related changes
test
: test related changes
chore
: chores, maybe ancillary functions related
build
: build process related
ci
: continuous integration related
docker
: docker image building related
revert
and Revert
: the revert message generated by some tools is uppercase.
bodyRequired
: if true, message body must be contained. (not only message header)
lineLimit
: length limit of every single line, in bytes.
If there are no configuration files, the program will use the following default configuration:
{
"lang": "en",
"scopeRequired": false,
"bodyRequired": false,
"lineLimit": 80
}
Localization
The program has built-in two languages: English (en) and Chinese (zh).
You can add language support in two ways:
Contributing code
The built-in languages are placed in the lang
directory, with individual .go
source file for each. You can copy lang/english.go
, change the file name and translate the content, then commit it to launch a Pull Request. The language will be added in next release after the PR is approved.
Of course, considering my limited English (my Chinese wording is not necessarily good either), you can also help improve the existing language support.
Add translation file
However, committing code may not be the best way to go.
Firstly , committing code is time-consuming. If you can't compile it yourself, but have to wait for next version release after the code merged in, it would be a long time until the version is ready. On the other hand, this is only a small tool after all, and to avoid the program becoming bloated, some languages may not be merged in, depending on the number of users.
You can choose a quicker way: adding translation file.
To do this, copy the commit-msg.en.json.sample file in the project root directory, remove .sample
from the file name, and change en
to the corresponding language (e.g., the abbreviation for language to be supported is xx
) . Translate the contents of the file, keeping the formatting verb %s
and the line break \n
. Then put the file in the same directory as the configuration file (home
directory or hooks
directory). Afterwards, remember to change the language configuration to the corresponding language (xx
in this case).
Unlike the configuration file, if the translations for the same language exist in both home
directory and hooks
directory, the contents of both will not be merged, but the translation in hooks
directory of the project will prevail. The contents of each language file must be a complete translation.
More info
The project was first inspired by validate-commit-msg . ( It has now been moved to conventional-changelog/commitlint )
For more information about conventionalcommits
, please see https://www.conventionalcommits.org/