19

How can I create a global pre-commit hook that is available for everyone in the team to use? Basically, I want that anytime someone clones the remote repository he should get this global pre-commit hook by default.

I came across this change default git hooks, Git commit hooks - global settings and this https://coderwall.com/p/jp7d5q where it suggests to create a template directory having common hooks and set init.templatedir to point to this directory. However this is useful only for setting default hooks for yourself on your own machine. How can the pre-commit hook be made available to entire team by default?

Community
  • 1
  • 1
phoenix
  • 795
  • 1
  • 7
  • 14
  • The only way you're going to get this done is by having people's accounts set up with this infrastructure in place already (and there's nothing keeping them from deleting it later). – Chris Hayes Aug 22 '14 at 07:06

3 Answers3

17

Luckily there is not a way to force hooks to people upon clone.

If there was, you could write a post-receive hook with rm -rf / in it and wipe people's hard disk on pull

What you can do is set up a command to automatically install repository hooks locally. There are some software packages like husky which simplify this task. Basically you can configure it on the repo and then require people to run npm i as soon as they clone the repo, and from now on they will use the hooks that you specify on the repo.

You should only do it with people you trust though, as once you install the hooks with npm i command you expose yourself to the attack specified above

pqnet
  • 6,070
  • 1
  • 30
  • 51
14

How can the pre-commit hook be made available to entire team by default?

It can not, as I explained in "Difference between pre-push and pre-receive hook in git?"

And from a security standpoint, that'd be really kind of scary - no one should have the ability to force me to execute certain scripts whenever I run certain git commands

So:

But in any case, remember that a git commit --no-verify would bypass the pre-commit hook anyway.

That is why a server-side hook is safer (as discussed in "Difference between pre-push and pre-receive hook in git?") and will catch all bad commits pushed to a blessed repo.

That is not say a pre-commit hook is useless: if you can convince the users to activate it, it will help catch error sooner, which is a good thing.
But it cannot be enforced "automatically".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for clearing my concepts. I understand a pre-receive hook would be better choice for my use-case. I was curious about global pre-commit hook because "it will help catch error sooner, which is a good thing". – phoenix Aug 22 '14 at 08:51
4

https://github.com/rycus86/githooks is a really option for managing hooks

It is...

  1. safe (it uses an opt-in model, where it will ask for confirmation whether new or changed scripts should be run or not (or disabled))
  2. configurable
  3. handles a lot of the details for you
  4. lets you keep your hooks nicely organized. For example:
/
└── .githooks/
    └── commit-msg/
        ├── validate
        └── add-text
    └── pre-commit/
        ├── 01-validate
        ├── 02-lint
        ├── 03-test
        ├── docs.md
        └── .ignore
    └── post-checkout
    └── ...
    └── .ignore
    └── .shared
    └── .lfs-required
├── README.md
├── LICENSE
└── ...
Tyler Rick
  • 9,191
  • 6
  • 60
  • 60