Semantic Git Hooks

This repository contains implementation of git hooks as pure bash scripts. Goal of implemented hooks is to support idea of semantic releases. So it restricts developer from doing meaningless, improper formatted commits. As a result it would allow automate tracking changes just in git and provides an ability to automate changelog creation on releases.

Currently it provides the following hooks:

• commit-msg This hook checks for the correct message format and performs spell-checking of the commit message.
• pre-commit Verifies that committed changes is correctly spelled

Spell checking is based on external tools. Currently it supports hunspell and aspell. On some systems you may be required to install one of these tools manually.

Installing

You may install this repository as a submodule of your repo or simply clone it to your repo and remove .git directory from the cloned repo:

Install As Submodule

cd ./my/project/workdir
git submodule add https://github.com/Mikhus/.git-hooks.git
./.git-hooks/scripts/init
git commit -am "chore: added .git-hooks as submodule to qualify commits"
git push

Now anyone would be able to pull .git-hooks from your repo. If you want to rely on your personal hooks implementation, feel free to fork it and submodule from your own or organization fork, so you would be able to manage your own changes and still will have possibility to merge from a source repo if needed.

When anyone is cloning your repository first, make sure adding --recursive option to clone command, as:

git clone --recursive [your_repo_url]

Installing As Part of Your Repo

cd ./my/project/workdir
git clone git@github.com:Mikhus/.git-hooks.git
rm -rf .git-hooks/.git
./.git-hooks/scripts/init
git commit -am "chore: added .git-hooks as submodule to qualify commits"
git push

Now you may commit and .git-hooks to your project repo to share it between teammates.

Enabling/Disabling

As simple as:

cd ./my/project/workdir

# Enabling
./.git-hooks/scripts/init
# or, if you want to enable only specific hooks
./.git-hooks/scripts/init commit-msg

# Disabling
./.git-hooks/scripts/reset

You may want to automatically enable hooks for everyone in your team. There is no other way to do it only by imploding the init command, for example in your install or build tool, so whenever someone will run install or build the hooks will be automatically initialized. For example in your Makefile:

SCRIPT_ROOT = .git-hooks/scripts

all: init
.PHONY: all

init:
	@$(SCRIPT_ROOT)/init
.PHONY: init

Or in your package.json

{
  "name": "my-cool-project",
  "version": "1.0.0",
  "scripts": {
    "start": "./.git-hooks/scripts/init ; /usr/bin/env node ./index.js",
    "install": "./.git-hooks/scripts/init"
  }
}

I guess you've caught an idea :)...

Of course it does not give a 100% warranty that improper commits will be published, but that may be achieved only with installing server-side hooks and that option is not always available, so having at least this kind of protection is better than nothing.

Scripts

This is not only hooks repo. There are couple of other useful scripts delivered under script directory

• init/reset - already described, them are used to disable/enable hooks
• spell - mostly used to perform spell-checking of the given input. Accepts two arguments - string (or multiline string) input and verification type. Second one is optional, but relies on a git work directory, so will try to find all the places where misspelled words in a current commit diff. With a single argument would treat it as a commit message, but who prevents of using it in other ways, or in another hooks? Examples:

  ./.git-hooks/scripts/spell "Wht wng with you?"
  ./.git-hooks/scripts/spell "$(git diff --cached | grep -e "^+[^+]")" "git"

• version - assumes your git repository uses semantic version tagging for your releases. If so, may help to determine semantic version of current commit or to build the next release version tag, for example:

  # get current version
  ./.git-hooks/scripts/version
  # get next prerelease version
  ./.git-hooks/scripts/version prerelease
  # get next patch version
  ./.git-hooks/scripts/version patch
  # get next minor version
  ./.git-hooks/scripts/version minor
  # get next major version
  ./.git-hooks/scripts/version major

  It is safe to run as it does not modify your repository. This could be useless on NPM based developments, but can be dramatically helpful in many other cases.

License

ISC

Happy Coding!