Can Git hook scripts be managed along with the repository?

Question

We\'d like to make a few basic hook scripts that we can all share -- for things like pre-formatting commit messages. Git has hook scripts for that that are normally stored

Answer 1

Ideally, hooks are written in bash, if you follow the sample files. But you can write it in any language available, and just make sure it has the executable flag.

So, you can write a Python or Go code to achieve your goals, and place it under the hooks folder. It will work, but it will not be managed along with the repository.

Two Options

a) Multi Scripts

You can code your hooks inside your help, and add a small fragment of code to hooks, to call your perfect script, like this:

$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/myprecommit.js

b) Single Script

A cooler option is to add just one script to rule them all, instead of several ones. So, you create an hooks/mysuperhook.go and point every hook you wanna have to it.

$ cat .git/hooks/pre-commit
#!/bin/bash
../../hooks/mysuperhook.go $(basename $0)

The parameter will provide your script which hook was triggered, and you can differentiate it inside your code. Why? Sometimes you might wanna run the same check for commit and push, for instance.

And then?

Then, you might want to have further functionalities, like:

• Trigger the hook manually to check if everything is ok even prior to a commit or push. If you just call your script (option a or b) would do the trick.
• Trigger the hooks on CI, so you don't need to rewrite the same checks for CI, it would be just calling the commit and push triggers, for instance. The same as the above should solve it.
• Call external tools, like a markdown validator, or a YAML validator. You can make syscalls and need to handle STDOUT and STDERR.
• Make sure all developers have a simple way to install the hooks, so a nice script needs to be added to the repository to replace default hooks with the correct ones
• Have some global helpers, like a check to block commits to develop and master branches, not having to add it to every repository. You can solve it by having another repository with global scripts.

Can this be simpler?

Yes, there are several tools to help you manage git-hooks. Each of them is tailored to tackle the problem from a different perspective, and you might need to understand all of them to get the one which is best for you or your team. GitHooks.com offers a lot of reading about hooking, and several tools available today.

As of today, there are 21 projects listed there with different strategies to manage git hooks. Some only do it for a single hook, some for a specific language, and so on.

One of those tools, written by me and offered for free as an opensource project, is called hooks4git. It is written in Python (because I like it) but the idea is to handle all items listed above in a single configuration file called .hooks4git.ini, which lives inside your repository and can call any script you want to call, in any language.

Using git hooks is absolutely fantastic, but the way they are offered usually only gets people away from it.

Answer 2

Theoretically, you could create a hooks directory (or whatever name you prefer) in your project directory with all the scripts, and then symlink them in .git/hooks. Of course, each person who cloned the repo would have to set up these symlinks (although you could get really fancy and have a deploy script that the cloner could run to set them up semi-automatically).

To do the symlink on *nix, all you need to do is:

root="$(pwd)"
ln -s "$root/hooks" "$root/.git/hooks"

use ln -sf if you're ready to overwrite what's in .git/hooks

Answer 3

How about git-hooks, it route .git/hooks invoke into script under project directory githooks.

There are also lot of features to enable you minimize copy and symlink hook all over the place.

Answer 4

You could use a managed solution for pre-commit hook management like pre-commit. Or a centralized solution for server-side git-hooks like Datree.io. It has built-in policies like:

1. Detect and prevent merging of secrets.
2. Enforce proper Git user configuration.
3. Enforce Jira ticket integration - mention ticket number in pull request name / commit message.

It won't replace all of your hooks, but it might help your developers with the most obvious ones without the configuration hell of installing the hooks on every developers computer/repo.

Disclaimer: I am one of Datrees founders

Answer 5

We are using Visual Studio solutions (and thus projects) which have pre and post build events. I'm adding an additional project named 'GitHookDeployer'. The project self modifies a file in the post build event. That file is set to copy to the build directory. Thus the project is build every time and is never skipped. In the build event, it also makes sure that all git hooks are in place.

Note that this is not a general solution, as some projects, of course, have nothing to build.