On Sun, 21 Jun 2020 17:15:44 +0000, Johnny Billquist wrote: ... > Even when you have unit tests (which you should), there are still plenty > of errors not caught by that. However, automatically running unit tests > on all code to be committed, *before* it is committed, is also very > valuable.
In git, commits are not final, and you can undo or 'modify' them.[1] Therefore there is no reason to require running tests before committing, but it rather makes sense to run tests on the *committed* state. For one, this way you see if you actually committed everything that is needed, and you still can replace the commit by a modified one if tests failed. E.g. on our primary product the developers can take the current commit in their workspace (repo), and run the CI tests on them on a server. The command that triggers this takes the current local commit, pushes it to a test repo, and a host in the test server farm picks that up. You can do that before even pushing to your branch in the central repo, i.e. before anybody seeing your commit. - Andreas [1] Still, on your central repo and branches you will disable removal of commits for the obvious reasons. -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800