Menu
Let's say you are working with or supporting a developer team of 20 people and want to use git pre-commit hooks as a way to enforce some validations on code that's being committed or pushed. Example, you want to make sure people dont check in large assets or debug-versions of SWF files, you also want to check if code has enough test coverage etc.
1.) There should be a central place where these hooks can be managed
2.) They should be automatically updated across all users/machines
474
It will work, but it will not be managed along with the repository.
If you want to manually run all pre-commit hooks on a repository, run pre-commit run --all-files . To run individual hooks use pre-commit run <hook_id> . The first time pre-commit runs on a file it will automatically download, install, and run the hook.
The pre-commit hook is run first, before you even type in a commit message. It's used to inspect the snapshot that's about to be committed, to see if you've forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.
I've been having some luck with putting some git setup and bootstrap config into the build itself.
In that manner, you could manage the .git/hooks directory by adding a phase to your build that syncs .git/hooks with a committed conf/git-hooks.
This will probably work pretty badly if your developers use only their IDEs to build/run/test the code, and any locally running hooks can be disabled or skipped by the developer.
You can put some of the hooks (large asserts, debug SWF checks) on your central repo, see the post-receive and update hooks.
If you need more flexibility, something like Gitolite's virtual refs functionality would let you allow only specific developers to flaunt the rules.
51
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
