@codeinabox I've got one to ask if I'm sure when I'm committing to anything called master or main. Helps prevent working in the wrong branch.I don't need to only catch that at the push stage and then have to rebase 🤷🏻‍♂️

Everytine I've seen a pre-commit hook in my job, it was something that should have been in integration pipeline.

You should not run linter, test or any static analysis tool in a pre-commit (I'm looking at you husky 😡). Why ? Because:

• It takes time. A commit should be instantaneous.

• It may change the content of the commit or of the repos without explicite action of the developer.

• The developper's branch is the developper's mess. He don't have to respect any convention, any quality gate or any workflow on its branch. Quality gates should happen only when integrating into trunk.

I always commit and push on Friday afternoon before leaving as "WIP", in case my computer crash during week end. I don't want to address issues of a WIP job. I just want to backup my work.

I may commit several time per minute, and do a rebase latter. I don't want to spend 2min each time waiting for eslint to parse the repos. I don't want to fix styling because I now I will fix it later and rebase -i before pushing.

You can use custom pre-commit in your own workflow, but forcing all developer to have the same pre-commit is a bad idea.

Ehh each tool it's job. Wanted to agree but pre commit checks to keep secrets from entering the graph makes sense at every level for me. Anything that is too keep the git DB itself clean goes there. So if you have Conventional Commits standards precommit checks make sense. Checks for secrets. Tbh that's the furthest I've done for a precommit.

Pre push is a good place to start any orginzational checks though. Pipelines for tests and smell checks or anything fuzzy really (can normally be seen by maintainers in the merge requests). K8s (like fleet, argocd, etc) for ops checks (is this running, is the service accepting requests, etc).

Most or all of these problems, and several more, are solved by using pre-commit. The author vaguely alludes to having had troubles with tools like this, but that has not been my experience.

The problem with somebody bypassing the hooks (intentionally or unintentionally) is solved by running the hooks as part of your CI; if you don't allow merges that fail these checks, then people can't skip them. If you also squash merges as a rule, then every commit on your target branch will pass the checks

EDIT: I'll add that, IMO, hooks should never modify files. They should simply check that your code meets whatever requirements you want your code-base to meet