Skip to main content

Pre-Commit Hooks Automation

Pre-commit hooks automate formatting, linting, and secret scanning at the moment of commit, catching issues locally before they reach the repository. Paired with the same checks in CI, they enforce quality and security cheaply and uniformly.

Best Practice: Pre-Commit Hooks Automation

Pre-commit hooks are automated checks that run on a developer's machine whenever they commit code, catching problems before they enter the shared repository. Git provides the hook mechanism, and the popular pre-commit framework makes hooks easy to declare, share, and version across a team. Typical hooks format code, run linters, block large files, and scan for secrets. By shifting these checks left to the moment of commit, teams keep the mainline clean and reduce noise in code review. For leaders, this is cheap, high-leverage quality and security enforcement applied uniformly.

Step-by-Step Implementation Guidance

  1. Choose a hook framework such as pre-commit to manage and share hooks.
  2. Define hooks in a versioned config file committed to the repository.
  3. Add formatting and linting hooks to enforce style automatically.
  4. Add secret-scanning hooks to block credentials before they are committed.
  5. Keep hooks fast so they do not disrupt developer flow.
  6. Install hooks as part of onboarding so every developer runs the same checks.
  7. Run the same checks in CI as a safety net for anyone who bypasses local hooks.

Common Mistakes Teams Make When Ignoring This Practice

  • Relying only on local hooks, which developers can skip with a flag, and not enforcing in CI.
  • Slow hooks that tempt developers to bypass them routinely.
  • Letting hook configuration drift between developers instead of versioning it.
  • Running heavy test suites in pre-commit, which belong in the pipeline instead.
  • No secret scanning, allowing credentials to leak into history.

Tools and Techniques That Support This Practice

  • Frameworks: the pre-commit framework and Husky for JavaScript projects.
  • Formatters/linters: Prettier, Black, ESLint, Ruff, and gofmt.
  • Secret scanning: gitleaks, detect-secrets, and TruffleHog.
  • CI mirrors: the same hooks executed in GitHub Actions or GitLab CI.

How This Practice Applies to Different Migration Types

  • Cloud Migration: Lint and validate infrastructure-as-code at commit time to catch cloud misconfigurations early.
  • Database Migration: Validate migration script syntax and naming at commit before schema changes reach review.
  • SaaS Migration: Scan for leaked SaaS API keys at commit time to prevent credential exposure.
  • Codebase Migration: Enforce consistent formatting and linting across a migrated codebase from the first commit.

Checklist

  • A hook framework manages shared hooks.
  • Hook configuration is versioned in the repo.
  • Formatting and linting run on every commit.
  • Secret scanning blocks credentials locally.
  • Hooks are fast enough to keep developers in flow.
  • CI re-runs the same checks as a safety net.

During modernization and migration work, pre-commit hooks automation is most valuable when it is treated as a continuous discipline rather than a one-time setup. Teams that codify the practice, measure its outcomes, and review it regularly keep risk low and feedback fast as systems evolve. Start small with one team or service, prove the value with concrete metrics such as lead time and change failure rate, and then expand the practice across the portfolio. Pair it with the related practices in this library so that build, test, release, and operational concerns reinforce one another. Documenting decisions and automating enforcement makes the practice durable as people and priorities change, which is exactly what large, multi-team migrations demand to stay safe and predictable over time.