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 | 中文
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.
You can download the latest pre-built binary from here . However, only win64 binaries are available.
-
Golang -
stringer
go install golang.org/x/tools/cmd/stringer-
upx
makeThe 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-inenandzhare 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, thenscopemust take a value from the list. This setting takes effect only whenscopeis non-empty, and is independent ofscopeRequired.typesanddenyTypes: 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 addtypesfirst and removedenyTypeslater. The default type keyword list is:feat: new featuresfix: bug fixesdocs: documentsstyle: the style of the code, modifications that do not affect the running logicrefactor: refactoring (logical changes neither new features nor to fix errors)perf: performance-related changestest: test related changeschore: chores, maybe ancillary functions relatedbuild: build process relatedci: continuous integration relateddocker: docker image building relatedrevertandRevert: 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. Skip line length checking if the value is not greater than 0.
If there are no configuration files, the program will use the following default configuration:
{
"lang": "en",
"scopeRequired": false,
"bodyRequired": false,
"lineLimit": 80
}The program has built-in two languages: English (en) and Chinese (zh).
You can add language support in two ways:
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.
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, the name of the translation file should be commit-msg.xx.json) . 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.
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/