Git Hooks are really useful guys that help us to control interactions with Git. I would like to show you couple of samples of their usage.
First of all we should:
- create .githooks folder near the .git folder
- create a Makefile in the project’s root that will set githooks path and activate them
- fill the Makefile like in the sample below:
init: git config core.hooksPath .githooks git config advice.ignoredHook false
To force Makefile works, just enough to execute this command in the terminal:
If we are working in a feature branch workflow it would be pretty nice to have an issue name for each commit developer does. To realize it we could:
- create commit-msg file into the .githooks folder
- add a regex into the commit-msg file that will verify the commits messages:
#!/bin/bash commit_regex="(ISSUE-[0-9]+|TASK-[0-9]+|merge)" if ! grep -iqE "$commit_regex" "$1"; then echo "You have to add issue tag in the commit" exit 1 fi
If developer won’t set an issue tag in a commit message, he/she will get an error with request to add the issue tag.
Imagine, we would like each developer to use only corporation emails. So, to realize it we could:
- open the same commit-msg file in the .githooks folder
- add a regex into commit-msg file that will verify developer’s email:
#!/bin/bash USER_EMAIL=$(git config user.email) CORP_DOMAIN="@corp.company.com" if [[ $USER_EMAIL != *"$CORP_DOMAIN" ]]; then echo "Your email ($USER_EMAIL) has to contain this domain: $CORP_DOMAIN" exit 1 fi
If developer won’t set a corp email in the git project, he/she will get an error with request to add the correct email
Eventually I would like to highlight Git Hooks give us a soil (or better to say hooks?) for automation. Whether it be issue names collection for release or a simple censure in the commit messages.