

Setting up pre-commit tests with Git - dduvnjak
http://dduvnjak.pw/adding-pre-commit-tests-with-git/

======
hamdal
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.

~~~
dduvnjak
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.

~~~
hamdal
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.

------
yawaramin
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.

~~~
IanCal
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.

------
exDM69
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.

~~~
merqumab
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)

------
Simucal
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.

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

------
seanhandley
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.

------
IanCal
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.

