Hi Greg - thanks for the question.
In my 25+ years of experience with inner and outer loops, I can say that I'm more of a fan of using the pull request model as the ultimate gate for changes. I have certainly used pre-commit git hooks (which are hard to enforce across dev teams) and tools like Gerrit (which "capture" the code between the commit and push and allow you to run checks there).
While I would not every attempt to dissuade anyone from having good testing/pre-commit/pre-flight checks, I do think it is important to use a pull request type of model to gate changes. With GitHub Actions, you can set up required workflows (equivalent of pipeline scripts) to do things like security scans, trial builds, and run tests at multiple levels when a pull request is made. That gives you both powerful "pre-checks" before final merge and a standardized way of enforcing the checks across all changes - as opposed to having to rely on local commit checks only. As an example, you can look at the list of workflows that are used to validate changes for the "checkout action" at
https://github.com/actions/checkout/actions
As well, I've found that I am doing more and more of my changes in the GitHub browser interface or things like GitHub Codespaces which don't really require the same local clone/commit processes. In fact, if you're viewing a file in GitHub, and click the "." key or change the URL to start with "github.dev" rather than "github.com" you get a browser-based version of VS Code. In those situations, pre-commit hooks/checks don't really apply so that's another reason I'm a fan of utilizing the GitHub Actions workflows triggered on pull requests as the gating checks.
Hope this helps.