A pre-push hook runs locally, on your machine, every time you git push. If you can fail a build in CI for a regression, you can also fail the push that would have caused the regression. The fix loop tightens from “push, wait for CI, fix, push again” to “the regression never leaves your laptop.”

SiteCMD ships a hook installer in the CLI.

Install

In a project that has a .sitecmd/ directory (run sitecmd init first if not):

sitecmd check --install

This writes a .git/hooks/pre-push script that calls sitecmd check. The hook fires on every push and exits non-zero if your project’s score has regressed beyond the threshold in .sitecmd/config.json.

What the hook checks

By default, sitecmd check runs a fresh scan and compares against your stored baseline. It fails if:

The overall score dropped below the threshold in your config (or the --threshold flag if you set one).
The diff between this scan and the last shows the score got worse.

Add --strict to fail on any new issue, not just score drops:

sitecmd check --strict

Useful when you want zero regressions, even if your absolute threshold isn’t breached.

Customizing the threshold

The threshold defaults to whatever’s in .sitecmd/config.json. Override per invocation:

sitecmd check --threshold 85

Tweak this until it’s strict enough to be useful but not so strict it’s annoying. A common pattern is to start at “current score minus 5” and tighten over time.

Skipping a push

The hook is local. If you absolutely need to push past it (you’re fixing something urgent, you know it’ll regress temporarily), git push --no-verify skips all pre-push hooks. Use sparingly; the entire point is to make regressions visible.

When pre-push isn’t enough

A pre-push hook runs only on the machine of whoever’s pushing. If your team is split across machines, or if you want guarantees that hold up to “I forgot to install the hook,” CI is still the right enforcement layer. Use both: pre-push for fast feedback at the developer’s keyboard, CI for the trust boundary.

For CI setup, see Quality gates in CI.

Uninstalling

The hook is just a file at .git/hooks/pre-push. To remove it, delete the file:

rm .git/hooks/pre-push

If you have other hooks chained in the same file (some teams use husky or lefthook for hook orchestration), edit the file instead of deleting it.

Hook chaining

If your repo already uses a hook manager like husky or lefthook, run sitecmd check from inside their config rather than overwriting .git/hooks/pre-push. Example for lefthook:

# lefthook.yml
pre-push:
  commands:
    sitecmd:
      run: sitecmd check

Speed

A pre-push hook should be fast. Scans against staging URLs typically run in a few seconds. If your scan is slow (deep page-coverage, Core Web Vitals, etc.), trim it down for the hook context:

sitecmd check --threshold 85

This runs the same checks that CI would for a quick gate, without the deeper analyses that take longer.

For the underlying flags, see CLI reference under sitecmd check.