How to configure git hooks for all developers

Question

I want to apply consistent commit message rule globally for all developers to have jira issue in commit message.

Using enterprise github.

As found, it can be achieve using, .git/hooks/commit-msg file to updated accordingly.

Issue: How to apply this updated git hooks to available for all the developers. I don't see any changes appear on git status. Not sure if it has to configure different way so, commit-msg constrain will apply for all developers instead of locally one. Can you please guide on this.

Answer 1

Any files in .git/hooks are not part of the repository and will not be transmitted by any push or fetch operation (including the fetch run by git pull). The reason is simple enough; see below. By the same token, a developer who has a Git repository has full control over his/her/their .git/hooks directory and whether any pre-commit and commit-msg hook is run (git commit --no-verify will skip both of these hooks).

What all this means is that you cannot force a developer to use any particular pre-commit or commit-msg hook. Instead of making this happen (which you can't do), you should do what you can to make it easy for your developers to use some hook(s) that you supply. There are many ways to achieve this. In the examples below I'll mention pre-commit hooks rather than commit-msg hooks.

One very simple one is to have a script that you write as a setup command that:

1. clones the repository or repositories developers should use; then
2. adds to those clones the hooks that you'd like them to use.

If the clones already exist, this command can simply update the hooks in place, so that your developers can just run the setup script again if the hooks have changed.

Another is to have a script in the repository that installs symbolic links, so that .git/hooks/pre-commit becomes a symbolic link to ../../scripts/pre-commit. This path climbs back out of hooks and then .git and then reaches into scripts/pre-commit, which means that the script in scripts/pre-commit is the one that will be run. You can of course use different names, e.g., make .git/hooks/pre-commit a symlink to ../../.git-precommit, if you like. This method does of course require that your developers' systems support symbolic links.

Your scripts, whether they're all in the repository itself or in some separate repository or whatever, can be as simple or as fancy as you like, and you can write them in any language that you like. This applies both to "install some hooks" scripts, and to the hooks themselves. The only constraint is that the hooks must be able to run on the developers' machines. Note that there are entire frameworks for Git hooks, such as Husky and the various options on pre-commit.com.

One small warning: it's easy to go overboard here. I'll recommend that anyone contemplating setting up fancy hooks have a look at this blog post for instance. Your check on commit messages is an example of not going overboard: it's simple and fast and does not get in anyone's way.

Why hooks are not copied

Imagine if git clone did copy and install hooks. Then imagine that the hook in some repository includes this bit of pseudo shell script in, say, the post-checkout hook:

if [ ! -x /tmp/trojan-horse ]; then
    install-trojan-horse &
fi

As soon as you clone this repository, boom, you've been pwned.