We have the husky package/config included in several CHT repos, but its usage is inconsistent (and IMHO redundant and unnecessary).
cht-core:
Husky is installed and initialized.
It is configured to validate that you do not commit to master/main
cht-conf:
Husky is installed, but does not ever seem to be initialized so, I don’t think it actually does anything.
It is configured to use commitlint to lint each commit message to be conventional.
cht-watchdog:
Husky is installed an initialized
It is configured to use commitlint to lint each commit message to be conventional.
cht-sync:
Husky is not installed/configured
I believe we can remove Husky and its config from our repos. GitHub provides the ability to prevent commits to master/main. Also, all 4 of these repos have a GitHub action configured to lint the PR title with commitlint to ensure the eventual commit to master/main has the proper format. Personally, I do not see much value in forcing all commits to random feature branches to have to follow commitlint.
However, I wanted to open this topic out here and see if anyone had strong opposing opinions! I am absolutely open to keeping husky, but I do think we should decide on how we want to use/config it and keep that consistent across these repos…
It does, but this stops all commits. This means that there is no CI bot that can push automatic release commits, which is something that we use in many repositories. This is the reason we used husky to prevent commits at the developer level.
I will admit that I am not entirely sure of the specific use case there. If our CI scripting is so wak that it could be accidentally making commits to master, that seems like a different problem that is not helpfully solved by husky…
That being said, for cht-core (and any other repos where are are not using semantic-release), I have not thought of any reason where we would need CI to be making direct commits to master. So, I think I am okay with leaving that config in place.
However, any repos using semantic-release really do benefit from the CI being able to automatically update the main branch during the release. Maybe we can just remove husky from those repos?
No
We need to keep direct pushes to main branches open, so CI bots can release.
What has happened is that developers have accidentally pushed to main branches from local development, so husky is meant to protect against that.
I think the bypass option didn’t exist back when we added husky.
I agree it’s the better option than husky, unless we want to use husky for something else as well.
So it is to protect from rouge CI bots…
If our CI scripting is so wak that it could be accidentally making commits to 
