.gitignore パターンテスター｜除外チェーンを 1 画面で逆引きする検証ボード

.gitignore の *.log と !important.log のような否定チェーン、node_modules/ の末尾スラッシュ、**/build/ の二重アスタリスクが「実際にどのパスを除外して、どのルールが効いているのか」を、git にコミットする前に 1 画面で確認できるツールです。各パスには Ignored / Kept のバッジと、最後にマッチしたルール本文 + 行番号が並びます。

💡 このツールについて

.gitignore は書いたつもりが効いていない、消したつもりが残っている、否定で復活させたつもりが他のルールに上書きされている、というのが起きやすいファイルです。git check-ignore -v を 1 ファイルずつ叩いて確認する代わりに、左にルール全文、右にパスのリストを貼り付ければ、上から下まで最終判定とマッチ行を一括で読めます。

モノレポで dist/ build/ coverage/ を片っ端から除外したい、!keep-this.log で 1 件だけ残したい、__pycache__/ を再帰的に潰したい、といった編集を .gitignore に commit する前に、サンプルパスに対して 8 件まとめて流して結果を見るのが想定運用です。

不正な glob（閉じていない [、誤ったエスケープ）があれば、結果リストの先頭に赤いバナーで通知され、その行だけスキップして他のルールは評価が続行されます。

🧐 よくある質問

Q. ルールの優先順位は git と同じですか? A. はい。上から順に評価して、最後にマッチしたルールが最終判定になります。*.log の後に !important.log を書けば important.log は Kept、逆順なら Ignored になります。

Q. ディレクトリ限定の指定（末尾 /）はどう扱われますか? A. node_modules/ のように末尾スラッシュを付けると、ディレクトリ配下のパス（node_modules/foo/bar.js）だけがマッチします。node_modules という名前のファイルは無視判定の対象外です。

Q. **/build/ のような二重アスタリスクは動きますか? A. 動きます。**/ は「任意の階層」を意味し、a/build/x a/b/build/x のいずれも除外対象になります。末尾に ** だけを置いた場合は「以降のすべて」を意味する git 仕様に合わせて評価します。

Q. .gitignore ファイルが複数ある場合は? A. このツールは 1 つのルールセット単位での検証用です。複数の .gitignore を結合した最終結果が知りたい場合は、上位 → 下位の順に内容を結合してから貼り付けてください。git の挙動と同様、下位ディレクトリのルールが上位を上書きします。

Q. # で始まる行はどうなりますか? A. コメント行として無視されます。値として # を残したい場合は \# でエスケープしてください。

Q. パスの先頭の ./ や / は? A. 評価前に正規化されて先頭の ./ と / は剥がされます。/dist/ のような anchor 指定はパターン側で行います。

📚 .gitignore の挙動を読む豆知識

.gitignore は git 1.0 から存在しますが、現在の挙動を厳密に決めているのは gitignore(5) の man ページで、glob 風の独自構文に「行の順序」「否定」「ディレクトリ限定」「アンカー」という 4 つの軸が乗っています。とくに「最後にマッチしたルールが勝つ」という後勝ちルールは、Cargo.lock や package-lock.json を一旦除外して特定パッケージだけ残すといった例外運用で多用される一方、誤った順序で書くと「除外したつもりが復活している」状態を引き起こします。

後勝ちと並んでハマりやすいのが「親ディレクトリが除外されたら、その配下のファイルを !parent/child で再包含することはできない」という挙動です。gitignore(5) 仕様にも明記されていて、git は除外されたディレクトリを列挙しない最適化のため、配下のパターンが評価されません。dist/ の後に !dist/keep.txt を書いても keep.txt は git に追跡されない、というのが典型例で、本ツールも判定理由欄に「親ディレクトリが除外済み」と表示してこの挙動を再現します。

国内のチーム開発では、GitHub の github/gitignore リポジトリにある Node / Python / Unity 用テンプレートを丸ごとコピーした後、自社の out/ dist/cache/ を追記するパターンが定番です。この時、テンプレートが先頭に *.log を持っていて、後段に !important.log を追記したつもりが他の *.log 系ルールに紛れて効いていない、というのがレビューでよく見つかる罠です。本ツールに pattern + path セットを通して、目視で「どの L 番号がどのパスに効いているか」を 1 行ずつ確認すると、追記の競合が見つけやすくなります。