[andreineculau]

the article talks about pre-commit hook, but nobody stops you from running these checks as pre-push hook. and nobody says you need to run the all the checks that you'd normally run on CI, but just enough checks to get past the silly errors.

for small repos, running linters and such on pre-push is great because you definitely don't have unlimited CI agents, so a lag of 10 seconds for a "git push" might mean you actually gain 30 minutes and not wait for an agent to be available and you also save your team some good minutes with a silly CI job failing with "missing whitespace".

PS: if you want to skip the pre-push hook once in a while, just run "git push --no-verify"

[webmonkeyuk]

Having to wait 30 mins for a build to run sounds like the real issue here. How would you push out an an emergency release in a timely way for example?

[andreineculau]

In a real emergency situation, there are all sorts of solutions to get a fix out and fast. But that almost never happens, thus it's not something to optimize for.

[majkinetor]

That may also depend on how many commits wait in the line. If team is large or monorepo, you need to wait for all pushes to pass in order for your own push to be tested which might take a long time even if single test is fairly fast.