I tend to work the other way around - what is defined in CI steps gets added to pre-commit. Several tools have already existing configurations or you can use local mode. Sure, I can't force people to use it but it saves them time as CI would fail anyway.

This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.

They're very commonly used in CI. There are dedicated GitHub actions for pre-commit and prek, but most commonly people just invoke something like `prek run --all-files` or `pre-commit run --all-files` in their typical lint CI jobs.

The prek documentation has a list of many large projects (such as CPython and FastAPI, to name a few) who use it; each link is a PR of how they integrated it into CI if you want to see more: https://prek.j178.dev/#who-is-using-prek

You can obviously bypass them, but having precommit hooks to run scripts locally, to make sure certain checks pass, can save them from failing in your pipeline, which can save time and money.

From an org standpoint you can have them (mandate?) as part of the developer experience.

(Our team doesn't use them, but I can see the potential value)

I think there's value in git hooks, but pre-commit is the wrong hook. This belongs in a hook that runs on attempted push, not on commit.

They integrate well with CI.

You run the same hooks in CI as locally so it's DRY and pushes people to use the hooks locally to get the early feedback instead of failing in CI.

Hooks without CI are less useful since they will be constantly broken.

The value is in finding out something is going to fail locally before pushing it. Useful for agents and humans alike.

Besides during commit, pre-commit/prek can run all hooks with `run`. So in CI/CD you can replace all discrete lint/format tool calls with one to pre-commit/prek. E.g. https://github.com/python/cpython/blob/main/.github/workflow....

I like my pre-receive hooks.