I'm not sure if this is a good practice. As project grows, running tests takes more time - remember that tests are not only unit tests which should run quickly, there are acceptance tests which can take some time to run. Waiting for commit to finish can become painfully slow.

Additionally, I like to commit partial solutions to feature branch as I work. Later I will fix the mess with rebase - this workflow wouldn't work.

You need CI anyway, so I'd leave tests there, and let the developer decide when to run the unit tests on his machine.

This example runs unit tests only, so it doesn't take too long (integration and other tests would still have to be executed on CI). It's more of a convenience than a practice, so you basically don't have to think about running unit tests.

Sure, if you find it convenient - go for it. However, I'd not enforce it as a policy for whole organisation for the reasons outlined above.

IMO we shouldn't have to jump through hoops to be able to commit. Let people commit whatever they want and then run tests to decide if you want to merge in their branches.

The workflow should encourage people to commit early and often to safeguard the work they've been doing as much as possible. It's very frustrating to lose work because it wasn't in the git object store.

True, although I've used something similar that compiles the code and runs tests, if they failed it asked if I still wanted to commit. It was just a quick check that I was probably committing what I thought I was.

Wouldn't it be a lot better choice to make this a post-receive hook on your Git server? E.g. run the tests before code gets accepted to master.

I often intentionally commit code that doesn't work (pass tests or even compile), but not to master branch. One of the big advantages of Git is that you can share code with your team mates even if that code doesn't work yet.

You could always set the script to only run the tests on certain branches on pre-commit. (i.e. if branch name is not master, exit 0)

At my work I setup a pre-commit hook that my team uses to run Uncrustify, a source-code beautifier. If the style of the commit doesn't match our rules for that language it will spit out a command for you to run to fix it. I think overall it has been a big win for our team. Uncrustify runs almost instantly and having a uniformly styled code-base is worth the small inconvenience.

I've been doing this from my make file every build. That way, vim will take me right to the error.

I can see this working if you're collaborating without Github's pull requests.

Personally I'd want to scope it to only run the test suite for merge commits onto the master branch since it's reasonable in development branches to commit changes with failing tests.

Warning, this won't check the code you're committing, it'll check the code you have in your working directory. You need to stash all non staged changes before running the tests.