Gitフックを制する者は開発を制す：`core.hooksPath` でプロジェクトの「作法」を強制同期せよ
いいか、チーム開発において最も高くつくコストは「コードを書く時間」ではない。「ケアレスミスによるCIのやり直し」と「レビューで指摘するまでもない些細な規約違反」だ。
各プロジェクトの `.git/hooks` 配下にスクリプトをコピーして回る時代は終わった。今回は、Gitの深淵を知る者だけが知る、「Gitフックの一元管理術」を伝授する。これを知れば、君のチームの開発環境は劇的にクリーンになる。
—
1. なぜ `.git/hooks` に直接書くのが「悪」なのか
Gitのデフォルトのフックディレクトリは `.git/hooks` だ。だが、ここには致命的な欠陥がある。
- Gitの管理外: `.git` ディレクトリ内はリポジトリの履歴に含まれない。つまり、チームメンバー間でフックの更新を共有できない。
- 分散管理の限界: 複数のリポジトリを持つ環境で、一つひとつにスクリプトを配布・更新するのは悪夢だ。
解決策はシンプルだ。「フックをリポジトリ内に配置し、Gitにその場所を教え込む」ことだ。
2. 実践：`core.hooksPath` を使った一元管理の極意
プロジェクトルートに `.githooks/` ディレクトリを作成し、そこにすべてのフックを集約させる。
ステップ1: フックディレクトリの構築
mkdir .githooks
例: コミット前にフォーマットを強制する pre-commit
touch .githooks/pre-commit
chmod +x .githooks/pre-commit
ステップ2: Gitへのパス適用
以下のコマンドを叩くだけで、そのリポジトリは指定したディレクトリをフックのマスターとする。
git config core.hooksPath .githooks
テックリードからの助言:
これだけではチームメンバーが手動設定を忘れる。プロジェクトルートに `setup.sh` を用意し、クローン直後にこのコマンドが走るようにするのが鉄板の作法だ。
—
3. 実用例：チームの生産性を底上げする `pre-commit` 構成
単なるリンターの実行だけでなく、セキュリティと品質を担保するスクリプト例を挙げる。
!/bin/bash
.githooks/pre-commit
1. 秘匿情報の漏洩チェック（gitleaksなどは必須）
if ! gitleaks protect –staged –verbose; then
echo “❌ 秘匿情報が検知されました！コミットを中止します。”
exit 1
fi
2. 変更差分だけフォーマット（lint-staged的なアプローチ）
STAGED_FILES=$(git diff –cached –name-only –diff-filter=d | grep -E ‘\.(js|ts|go|rs)$’)
if [ -n “$STAGED_FILES” ]; then
# ここで適宜フォーマッタを呼ぶ
echo “🔍 ファイルチェック中: $STAGED_FILES”
# lint系コマンドが失敗したらコミットを中断
fi
exit 0
—
4. 現場で震えるほど役立つ「プロのハック」
① 設定ファイル共有のベストプラクティス
フックの内容を `YAML` で定義し、CIとローカルで挙動を共通化するのがプロの技だ。
.hooks-config.yaml
rules:
- name: “Secret scan”
command: “gitleaks protect –staged”
- name: “Conventional Commits”
command: “commitlint –edit”
これを各フックスクリプトから読み込むようにすれば、言語やフレームワークが変わっても管理コストはゼロになる。
② 神プラグイン：`husky` を超える柔軟性を
Node.js環境なら `husky` が主流だが、汎用的な環境では `lefthook` を強く推奨する。設定ファイルがYAMLで完結し、並列実行も可能。Gitフックの管理における「最終回答」だ。
③ セキュリティ上の注意点：バイパスの誘惑
`–no-verify` を使えばフックは回避できる。だが、チームの文化として「フックをバイパスする正当な理由」をPRの概要に必ず記載させる運用を徹底せよ。
—
5. 結論：環境を「自動で整う」状態にする
優秀なチームは、環境構築を「人間がやる作業」とは考えていない。
`core.hooksPath` を活用し、「クローンした瞬間に、そのチームの規約が強制的に適用される」仕組みを構築すること。それが、君がテックリードとして最初にやるべき「レバレッジの効く仕事」だ。
設定は一度きりではない。常に磨き続けろ。Gitは単なるソース管理ツールじゃない。君たちの開発プロセスそのものだ。
さあ、今すぐ `.githooks` を作成して、チームのエンジニアたちを驚かせてやれ。