Git Hooks Setup

wu529778790/shenzjd-skills/git-hooks-setup

作者 wu52977879091d81223806690723b86b0cc06dc65a29568c1ad无许可证收录于 2026年10月9日更新于 2026年10月9日

Use when setting up git hooks (pre-commit, commit-msg, pre-push) with husky or native hooks for linting, formatting, commit conventions, and secret scanning.

AI 生成的概览

配置 Git Hooks,用于代码检查、格式化、提交信息校验和敏感信息扫描。

功能
该技能指导配置 pre-commit、commit-msg 和 pre-push 钩子,支持 husky 与原生 git hooks 两种方案。它会检测项目的包管理器和已有钩子配置,然后生成钩子脚本、lint-staged 配置、commitlint 配置文件以及可选的敏感信息扫描检查。文档还列出了常见错误,例如钩子缺少执行权限或密钥关键字匹配范围过宽。
适用场景
适用于需要在提交和推送前自动执行代码检查、格式化或测试的项目,或团队希望统一提交信息格式的场景。也适用于在提交前加入密钥扫描。不适用于仅查看现有钩子配置、仅使用 CI 检查或项目已有完整钩子配置的情况。
运行要求
需要 git 仓库;使用 husky 方案时还需要 Node.js 项目及包管理器(npm、yarn 或 pnpm)。可选依赖包括 husky、lint-staged、commitlint 与 @commitlint/config-conventional,以及用于密钥扫描的 gitleaks。技能附带 commitlint 配置模板,并会生成可执行的钩子脚本。

Git Hooks Setup

一键配置 Git Hooks,标准化团队开发流程。

Overview

自动生成 pre-commit / commit-msg / pre-push hook 配置,包含代码格式化、commit message 校验、敏感信息检查。支持 husky 和原生 git hooks 两种方案。

When to Use

  • User wants to set up git hooks
  • User mentions pre-commit or commit message conventions
  • User wants to automate lint/format checks
  • User inputs /git-hooks-setup
  • User wants to enforce pre-push checks (tests, lint)
  • User wants to prevent pushing broken code
  • User wants to standardize team commit message format
  • User wants to add secret scanning before commit
  • User wants to auto-format code on every commit

When NOT to Use:

  • User only wants to view current git hooks configuration
  • User wants CI-based checks (no local hooks needed)
  • User's project already has a complete hooks setup
  • User wants to run hooks on specific files only (use lint-staged directly)
  • User wants to hook into Git events other than pre-commit/commit-msg/push

Core Pattern

Step 1: 检测项目环境

bash
# 检测包管理器(按 lock 文件判断)if [ -f "package-lock.json" ]; then PACKAGE_MANAGER="npm"elif [ -f "yarn.lock" ]; then PACKAGE_MANAGER="yarn"elif [ -f "pnpm-lock.yaml" ]; then PACKAGE_MANAGER="pnpm"
# 检测已有 hooks 配置test -d ".husky" && echo "husky 已配置"test -f ".git/hooks/pre-commit" && echo "原生 hooks 已配置"
# 从 package.json 检测已安装的 lint 工具(eslint/prettier/lint 相关)

Step 2: 选择方案

方案适用场景优点
huskyNode.js 项目团队协作友好,配置即代码
原生 git hooks非 Node.js 项目无依赖

Step 3: 生成配置

方案 A: Husky

bash
# 根据 $PACKAGE_MANAGER 选择: pnpm dlx / yarn dlx / npxhusky init    # 初始化 husky

生成 .husky/pre-commit(执行 lint-staged)和 .husky/commit-msg(执行 commitlint),注意 commitlint 需加 --no 前缀避免交互式安装。

生成 lint-staged 配置(写入 package.json):

json
{  "lint-staged": {    "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"],    "*.{json,md,yml}": ["prettier --write"]  }}

生成 .husky/pre-push(可选,push 前跑测试):

bash
# 根据包管理器选择命令if [ "$PACKAGE_MANAGER" = "pnpm" ]; then  pnpm testelif [ "$PACKAGE_MANAGER" = "yarn" ]; then  yarn testelse  npm testfi

方案 B: 原生 git hooks

bash
cat > .git/hooks/pre-commit << 'EOF'#!/bin/sh# 自动 lint + format(按项目实际替换命令;示例为 Node 项目)if [ -f "package.json" ] && [ -x "$(command -v npm)" ]; then  npm run lint -- --fix 2>/dev/null || true  npm run format 2>/dev/null || truefi# 注意:不要执行 git add -u —— 那会把用户未暂存的改动也一并提交。# 若需把 lint 修复的结果纳入提交,请使用 lint-staged(只处理暂存文件)。EOFchmod +x .git/hooks/pre-commit
# pre-push hook(可选,push 前跑测试;按项目实际替换)cat > .git/hooks/pre-push << 'EOF'#!/bin/shif [ -f "package.json" ] && [ -x "$(command -v npm)" ]; then  npm test || exit 1fiEOFchmod +x .git/hooks/pre-push

Step 4: 配置 Commit Message 规范

将 templates/commitlint.config.js 复制到项目根目录(commitlint.config.js)。该配置基于 @commitlint/config-conventional,校验 commit message 格式:

type(scope): subject
# type: feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert# scope: 可选,影响范围# subject: 简短描述(header-max-length 限制 100 字符)

同步安装 commitlint 依赖:

bash
npm install -D @commitlint/cli @commitlint/config-conventional

Step 5: 添加敏感信息检查

⚠️ 不要用 grep "password|secret|token" 这种关键字扫描 —— 业务代码里出现 "token"/"secret" 字样是常态,会大面积误报导致提交被频繁拦截。

推荐使用 gitleaks(专门做密钥扫描,内置熵检测 + 允许列表,误报率低):

bash
# 生成 gitleaks pre-commit hooknpx gitleaks git-config 2>/dev/null || brew install gitleaks && gitleaks git-config# 或手动在 .git/hooks/pre-commit 中加入:# gitleaks protect --staged --verbose 2>&1# 若 gitleaks 不可用,宁可跳过也不要退化成关键字 grep

如果确实无法安装 gitleaks,退而求其次也要避免整词误报 —— 只匹配高置信度模式(如私钥块、AWS 密钥格式),不要匹配 token/secret/password 这类业务常用词:

bash
# 低误报替代方案:只扫私钥和云厂商密钥格式(示例)if git diff --cached --diff-filter=ACM --name-only -z | xargs -0 grep -IlE "BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}" 2>/dev/null | grep -q .; then  echo "警告: 检测到可能的密钥泄露,请检查后重新提交"  exit 1fi

Quick Reference

bash
/git-hooks-setup                    # 交互式选择方案和 hooks/git-hooks-setup --husky            # 直接用 husky/git-hooks-setup --native           # 直接用原生 git hooks
参数说明默认值
--husky使用 husky自动检测
--native使用原生 git hooksfalse
--commitlint添加 commit message 校验true

Common Mistakes

错误正确做法原因
hook 脚本没有执行权限chmod +x .git/hooks/*hook 不会运行
lint-staged 配置太多规则只检查暂存文件减少提交等待时间
commit message 校验太严格先宽松后收紧避免团队抵触
不检查敏感信息加入密钥扫描防止泄露
.git/hooks 不提交用 husky/lefthook 管理团队需要共享配置
pre-push hook 跑太久只跑快速检查,完整测试放 CIpush 被阻塞影响效率
hook 中使用相对路径使用绝对路径或项目根目录不同目录执行时路径解析失败
跳过 prepare 脚本确保 package.json 的 prepare 运行 husky(v9+)CI 环境 hook 不生效
commitlint 规则与团队不一致使用 commitlint.config.js 统一配置口头约定容易被违反
不配置 --no-verify 白名单允许 --no-verify 但记录日志紧急修复时不能被完全阻断

来源与署名

来源:wu529778790/shenzjd-skills位于git-hooks-setup提交91d8122

许可证: 无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架