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 under <project>/.git/hooks/. However, those scripts are not propagated when people do a clone and they are not version controlled.

Is there a good way to help everyone get the right hook scripts? Can I just make those hook scripts point to version controlled scripts in my repo?

Answer 1

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 2

In Git 2.9, the configuration option core.hooksPath specifies a custom hooks directory.

Move your hooks to a hooks tracked directory in your repository. Then, configure each instance of the repository to use the tracked hooks instead of $GIT_DIR/hooks:

git config core.hooksPath hooks

In general, the path may be absolute, or relative to the directory where the hooks are run (usually the working tree root; see DESCRIPTION section of man githooks).

Answer 3

If your project is a JavaScript project and you use npm as package manager you can use shared-git-hooks to enforce githooks on npm install.

Answer 4

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 5

Most of the modern programming languages, or rather their build tools, support plugins to manage git hooks. That means all you need to do is configure your package.json, pom.xml, etc., and anyone in your team will have no option but to comply unless they change the build file. The plugin will add content to .git directory for you.

Examples:

https://github.com/olukyrich/githook-maven-plugin

https://www.npmjs.com/package/git-hooks

Answer 6

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.

Answer 7

You can make your hooks folder another git repository and link it as a submodule... I guess worth it only if you have a lot of members and hooks changed regularly.

Answer 8

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 9

pre-commit makes this easy for pre-commit hooks. Doesn't answer the OP's question about managing any arbitrary git hook, but pre-commit hooks are probably the most frequently used for code quality purposes.

Answer 10

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 11

For Nodejs users a simple solution is to update package.json with

{
  "name": "name",
  "version": "0.0.1",
  ......
  "scripts": {
    "preinstall": "git config core.hooksPath hooks", 

The preinstall will run before

npm install

and redirects git to look for hooks inside the .\hooks (or whatever name you choose) directory. This directory should mimic .\.git\hooks in terms of file name (minus the .sample) and structure.

Imagine Maven and other build tools will have an equivalent to preinstall.

It should also work across all platforms.

If you need any more info see https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/