概要

• Rustプロジェクトの開始から pre-commitフック の作成までの流れ
• pre-commitフック が抱える根本的な問題点の指摘
• pre-pushフック の推奨理由とその運用ポイント
• 具体的な フックスクリプト の改良例
• フック導入時の 注意点とベストプラクティス

Rustプロジェクトの初期セットアップとフォーマット管理

• 新規ディレクトリ best-fizzbuzz-ever 作成、 main.rs ファイル作成
• Gitリポジトリ の初期化と main.rs のコミット
• 他言語FizzBuzz集への追加時、 コードフォーマット統一 の要求
• rustfmt によるフォーマットチェック用 pre-commitフック 導入
  • 例:

    #!/bin/sh
    set -eu
    for f in *.rs; do rustfmt --check "$f"; done
    

• ステージングされていない変更を フックで検出できない 問題発生

pre-commitフックの改良と限界

• インデックス上のファイルを 一時ディレクトリ に展開しチェックする方式へ改良
  • 例:

    tmpdir=$(mktemp -d --tmpdir "$(basename "$(realpath .)")-pre-commit.XXXX")
    trap 'rm -r "$tmpdir"' EXIT
    git checkout-index --all --prefix="$tmpdir/"
    for f in $tmpdir/*.rs; do rustfmt --check "$f"; done
    

• 変更ファイルのみ チェックするようさらに改良
  • 例:

    files=$(git diff --name-only --cached --no-ext-diff --diff-filter=d)
    ...
    

• 既存コードが未整形 だとコミットできない問題
• rebase時 や Rustファイルがないコミット でフックが失敗するケース

pre-commitフックの根本的な問題

• 他人のブランチ や 古いフック には適用できない
• rebase や merge 時に意図せずフックが走る
• コミット単位 での品質担保が困難
• CIでの検証 と異なり、 ローカルのみ で完結してしまう
• 作業効率低下 や ワークフロー破壊 のリスク
• 作業ツリー全体 のチェックは大規模リポジトリで非現実的

pre-pushフック推奨理由と運用のポイント

• pre-pushフック なら、 push前 にまとめてチェック可能
• インデックス上 のファイルを対象にすることで、 一貫性確保
• 高速・信頼性重視のチェック のみ実装推奨
  • ネットワークアクセスやビルド必須のチェックは非推奨
• 静かな出力 でユーザー体験向上
• 自動セットアップ禁止、 手動設定手順をドキュメント化
• コミット前フック は機密情報（例: 認証情報）流出防止用途に限定

pre-pushフック作成時の具体的アドバイス

• インデックス上 のファイルでのみチェック実施
• 変更ファイル検出 は信頼できないため、 明示的なファイル指定 が望ましい
• CONTRIBUTING.md 等に 手動導入手順 を明記
• pre-commitフック は原則使用しない方針

まとめ

• pre-commitフック は多くの欠点があり、 pre-pushフック の使用が推奨
• 品質担保 はCIやpre-pushフックで実施
• 認証情報漏洩防止 以外でpre-commitフックは避けるべき
• 運用ドキュメント の整備が重要