10

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

parolkar
  • 369
  • 2
  • 8
  • 1
    Just as a comment: I would very, *very* strongly advise against any checks in pre-commit. One thing that makes git (or any DVCS) so valuable is the ability to make "quick'n'dirty commits" that you clean up before pushing. Having strong pre-commit checks destroys that benefit. Any such checking should be done on the server (in a pre-receive hook, or later as part of continuous integration). – sleske Apr 07 '14 at 06:49

2 Answers2

3

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.

Dwight Holman
  • 1,570
  • 14
  • 15
-1

I would suggest that you don't restrict a developer in the way he commits. Give him the liberty of prioritizing tasks according to himself. That being said, it is also important to maintain a structure in the coding style.

I would recommend that you use a build runner such as Team City to handle such kind of tasks. Setup some hooks on teamcity on the develop branch which will validate the code quality and send you very detailed report.

Also, some times you have to supply hotfixes to the customer and you don't really care about the code quality at that point of time. These cases become a real big problem to deal with when your system is filled with such nasty hooks.

tusharmath
  • 10,622
  • 12
  • 56
  • 83
  • 2
    This answer is the opposite of what the question is asking for. – Daniel Compton Apr 07 '14 at 04:36
  • @DanielCompton My approach is opposite indeed, because hooks would make the process slow. In my company the unit tests (1800 in number) take 45-50 mins to run and if each dev machine keeps running unit tests how do you expect them to make a commit? – tusharmath Apr 07 '14 at 06:31
  • @DanielCompton: True, but sometimes the right answer is: "Don't do this, do something else". This, I feel, is one of those cases :-). – sleske Apr 07 '14 at 06:50
  • 1
    @DanielCompton Lesson learnt :) I guess I was being too polite. – tusharmath Apr 07 '14 at 07:11
  • 2
    @sleske there are many uses of git pre-commit hooks apart from running tests. Avoiding checking in assets, enforcing a commit style or running a code formatter are reasonable pre-commit hooks. – Daniel Compton Jun 02 '14 at 08:27
  • git precommit hooks will enforce some basic and fast tests; setting up CI will ensure that unit tests/integration tests don't break and CD will ensure that there isn't a need for a panic commit. – Fabián Heredia Montiel Jun 11 '19 at 04:03