導入
皆さんのチームでは、「コミットした後にLinterエラーに気づく」「フォーマットの揺れでコードレビューが非効率になる」といった経験はありませんか？Git Hooksは、こうした人為的ミスを未然に防ぎ、開発フローを自動化するための強力な武器です。コミットやプッシュといった特定の操作をトリガーにスクリプトを走らせることで、品質管理を強制・自動化し、開発者が本来のビジネスロジックに集中できる環境を作ることができます。
基礎知識
Git Hooksとは、Gitリポジトリ内の特定のタイミングで実行されるスクリプトのことです。`.git/hooks` ディレクトリに配置されたシェルスクリプトが本体ですが、最近ではNode.js環境の Husky や、言語に依存せず高速に動作する Lefthook といったツールを使うのが主流です。これにより、スクリプトをリポジトリ内に含め、チーム全員で設定を共有することが容易になります。
実装/解決策
今回は、最も普及している Husky を使った実装例を紹介します。まずは、コミット時に必ずLinter（今回はESLintを想定）を走らせ、コードの品質を担保する仕組みを構築しましょう。
1. インストールと初期化:
npm install husky –save-dev
npx husky install
2. フックの追加:
npx husky add .husky/pre-commit “npm run lint”
これで、`git commit` を実行するたびに自動で `npm run lint` が走り、エラーがあればコミットが中断されるようになります。
サンプルプログラム
より実践的な例として、`lint-staged` を組み合わせた設定を紹介します。変更したファイルだけを対象にフォーマットをかけることで、実行時間を大幅に短縮できます。
// package.json に記述する設定例
{
“scripts”: {
“prepare”: “husky install”
},
“lint-staged”: {
// ステージングされたJavaScript/TypeScriptファイルのみを対象にする
“.{js,ts}”: [
“eslint –fix”, // 自動修正を試みる
“prettier –write” // フォーマットを整える
]
}
}
// .husky/pre-commit ファイルの内容
!/bin/sh
. “$(dirname “$0″)/_/husky.sh”
ステージングされたファイルに対してのみlintを実行する
npx lint-staged
応用・注意点
現場で活用する際の重要な注意点は2つあります。
一つ目は「実行速度」です。フックが重すぎると開発者のストレスになり、無効化される原因になります。`lint-staged` のように、必要な箇所だけをチェックする手法を必ず採用してください。
二つ目は「強制力のバランス」です。あまりに厳格なルールを課すと、急ぎの修正時に足かせになることがあります。`–no-verify` オプションを使えばフックをスキップ可能ですが、乱用は厳禁です。CI/CDパイプラインとの二段構えで、「ローカルでの即時フィードバック」と「CIでの厳密なチェック」を使い分けるのが、安定したDevOps運用の鍵となります。
コメント