Git hooks let you run automatic scripts before or after local events such as committing, pushing, or merging branches. They are a fundamental tool for maintaining code quality without relying solely on continuous integration. However, manually configuring them in each repository clone can be tedious and error-prone. That is where Husky comes in, a library that simplifies hook management and centralizes them in the project's .husky/ directory. In this article we will explore how to set up Husky v9 with lint-staged, cover useful hooks like pre-commit, commit-msg, and pre-push, see how to skip hooks in CI, and discuss best practices for development teams. This content not only serves as a technical guide but also shows how these tools integrate into broader automation, quality, and security strategies, such as those provided by Q2BSTUDIO in their custom software development projects.
Before diving in, it is important to understand the mental model: Husky does not invent a new hook system; instead, it points Git's core.hooksPath to the .husky/ directory. This means the hooks are standard shell scripts that Git executes natively. The advantage of Husky is that it automates the installation of these scripts through a prepare script in package.json. Thus, every time a developer runs npm install, the hooks are installed automatically without any extra manual steps. To get started, you need Node.js (version 20 or higher, though Husky v9 documentation recommends 18+), an initialized Git repository, and dependencies: npm i -D husky and optionally lint-staged, ESLint, and Prettier.
The command npx husky init creates the .husky/ folder with a default pre-commit hook and adds the prepare: 'husky' script to your package.json. This script runs after every npm install, ensuring all team members have the same hook setup. From there, you can edit the .husky/pre-commit file to run the checks you want. The most common practice is to use lint-staged, which limits linters and formatters to only the files in the staging area. This prevents slowing down the commit with analysis on the entire worktree. You configure lint-staged in package.json with an object that maps file patterns to commands, for example: '*.{js,ts}': ['eslint --fix', 'prettier --write']. Then, in the pre-commit hook, you simply run npx lint-staged. If any command fails (non-zero exit code), Git aborts the commit, acting as an early guard before bad code leaves your machine.
Keeping the pre-commit fast is critical. Therefore, only lightweight, file-local tasks should be included. Heavy tasks, such as the full test suite or whole-project static analysis, are better left for the pre-push hook or CI. The commit-msg hook is another important ally: you can validate the commit message format and, for example, block messages that start with 'WIP' or do not follow a convention. To do this, in .husky/commit-msg you read the file passed by Git as the first argument ($1) and apply a regular expression. If validation fails, you display a message and exit with code 1. Similarly, the pre-push hook can run a quicker subset of tests before pushing the branch to the remote, preventing changes that break the build from being uploaded.
Husky also provides ways to skip hooks when needed. Git has the --no-verify (-n) flag that bypasses all local hooks. Additionally, you can temporarily disable Husky with the environment variable HUSKY=0. This is useful in CI environments where running local hooks makes no sense (since CI runs its own validations). However, caution is needed: hooks are local and do not run on the remote, and anyone can bypass them. They should not be considered a security measure, but rather an aid for code quality. If you need security, cybersecurity should be implemented at the server level and through continuous integration policies.
Another relevant aspect is compatibility with Node version managers (nvm, fnm) in GUI environments. Graphical Git clients often do not have access to the same shell as the terminal, so they may not find the Husky binary. The recommended solution from Husky maintainers is to create a file ~/.config/husky/init.sh that loads the appropriate version manager. Also, in monorepos or projects with subdirectories, always install Husky at the repository root, not in nested packages, so that hooks apply to the entire project.
Husky and lint-staged are just one piece of the automation ecosystem. At AI agents and modern applications, code quality is a critical factor. Companies that develop custom software, like Q2BSTUDIO, integrate these tools into their CI/CD pipelines alongside cloud services like AWS or Azure, business intelligence with Power BI, and cybersecurity strategies. For instance, a pre-push hook could run quick unit tests before deploying to a cloud test environment. Or a commit-msg hook could enforce a format that later gets analyzed by a BI system to measure team productivity. All of this is part of an automation culture that reduces human errors and accelerates delivery.
In conclusion, Husky is a simple yet powerful tool for establishing local gates before code reaches continuous integration. Combined with lint-staged, ESLint, and Prettier, it offers a fast and effective filter that maintains codebase consistency. Remember that hooks are a complement, not a substitute for CI. The key is to use them for what they do best: lightweight, quick checks that give immediate feedback to the developer. If you want to take your project's automation to the next level, consider adopting these practices and rely on experts like Q2BSTUDIO, which offer comprehensive solutions in custom application development, cloud, cybersecurity, artificial intelligence, and BI.
