> Implement automation to flag and block/reject bad commit messages.

They'll just use `git commit -n` to skip the pre-commit hook.

And if it's verified in CI (e.g. with Danger), someone will just create a script to automate writing commit messages that pass the good commit message test.

And those are the people you fire because they refuse to follow policy and actively work to circumvent best practices and quality gates.

No way, (1) would annoy the heck out of people. Plus what if you want to just save off your current status and log off for the day..

Configure the enforcement only for `main` and other release/production branches, let people push whatever they want to their dev/feature branches.

When those branches are attempted to be merged they'll fail due to having bad commits and require fixing.

That's what git stash is for; you can even add a message, just like a commit, to the stash. A commit should always be in a good state, runnable, without lint or other errors.

Yes. In my experience, anything that prevents people from committing to local branches is incredibly annoying. You want people to commit frequently and “save their work.” Checks, quality barriers, etc. are fine at CI time.