I guess the argument for pre-commit hooks that lint and run unit tests would be that every single commit is clean.
The argument against them is that they take a lot of time to run, which can add up if you commit often.
The same would go for pre-push hooks except they presumably occur less often. Also, if you have continuous integration setup, which runs the same lint and test scripts you basically have to wait twice when the outcome will be the same almost all the time.
Yes, and no.
Is the action you are putting into the script worth it?
At work we have issues with git on windows environments. The file system is case-insensitive and leads to all sorts of fun. We using the pre-commit hook to ensure that all branch names are lower case. This is a quick check that saves a lot of hassle.
Our post commit hook checks to see if the branch being targeted is like /stream/xyz. If it is it also sends the commit message to the stream slack channel to notify team members who are not heavily involved with code management, but might like to know about work done (manager) or that some testing might be possible on the next build.
Is this your process?
Having a long commit time is a non-issue if that is the expectation on each developer. That they successfully run x, y, and z.
Similarly you could enforce this by checking for results. If the results are clean and date after all the files in your project, then its pretty self-evident that they were run and are good.
Then again this could be a waste of time and resources. Perhaps a dedicated CI box is better.
But all of this is hand-waving without a process you desire to implement. Only then can you determine if these scripting hooks are appropriate.
This depends a lot on your teams branch/merge and working model, on the quality of the linter rules, the quality of the unit tests and the actual running time of both.
When developers mainly commit to their local branch, or commit or push to an isolated feature branch, the influences of a non-clean commit on other team members are quite low, so they are usually tolerable. But assume a changeset is merged directly into a common dev branch, or into a shared feature branch, and the next dev pulls the unclean changes into his/her local working copy. Now when he/she notices failing unit tests, for example, then this will make the process quite ineffective, since it may not be clear any more whether the root cause were his/her own local changes, or the former merge.
If that is what you experiencing in your team, then a pre-push hook might be a useful solution. However, if the running time of those validations makes pushing a hassle, you should try to optimize. Maybe you can split the automated tests into a "slow" part which runs usually exclusively on the CI server, and a quick part which behave like "good" unit tests should behave - I mean, they should run very quick. That may help to streamline the process.
