Git hooks management

We use custom开发者_JAVA百科-written Git hooks in our project.

Hooks are stored in a project's repository, and, when they do change, to get a new version each user must copy them manually in his .git/hooks directory. This is rather inconvenient.

One way to improve this is to make .git/hooks a symlink into worktree. But this would imply that each branch (even user's local feature branches under development) should have the most current version of hooks. This is not convenient as well.

How would you solve the problem?

Maintain a separate repository of your hooks and symlink into that.

I agree, it'd be nice if Git had a built-in mechanism for propagating hooks scripts but it doesn't.

http://benjamin-meyer.blogspot.com/2010/06/managing-project-user-and-global-git.html appears to be a convenient way to automate hook symlinking, to facilitate global, per user, and per project hooks.

In Git 2.9, you can point to a custom hooks directory using the core.hooksPath configuration.

Git 2.9 Release Notes - https://github.com/blog/2188-git-2-9-has-been-released

Documentation mentioning core.hooksPath - https://git-scm.com/docs/githooks

Note - this question is a possible duplicate of Can Git hook scripts be managed along with the repository?

pre-commit has a bunch of features that look promising

• Works for many languages, and has a plugin architecture to add support for other languages
• Capable of bootstrapping the hook dependencies (language dependent)
• Applies hooks incrementally (only run hooks on changes that are part of the commit)
• Leverages the init.templateDir so newly checked out repos automatically install the correct hooks
• Temporarily disable a specific hook using an environment variable - don't skip all the checks just because you can't run one of them

Source code here

For NodeJS-based projects, I suggest you taking a look at ghooks.

You could make the repository's .git directory a git repository, and just add hooks and other config to it, adding the objects, refs, etc. directories and files like index to its .gitignore. Not only that, but you could set up a post-receive hook to update the metarepo from its origin. Once you had the initial configuration set up, you could have it pull in updates without any additional effort.

I'm working out the details of this, like what should go in the ignore list; I'm keeping the results in branches of this repo.

We made .git/hooks a symlink into the working tree.

For those rare occasions when someone needs to commit files that the hooks will reject, we use git commit --no-verify