.gitignore テスター

使い方

1. 最初の欄に .gitignore をディスク上のまま貼り付けます。コメント、空行、CRLF 改行、BOM はすべて git と同じ扱いになります。
2. 次の欄に、確認したいパスをリポジトリのルートからの相対で 1 行に 1 つ書きます。ディレクトリは 行末にスラッシュを付けてください。`logs/` のようなディレクトリ専用規則の判定がそれで変わります。
3. 表を読みます。各行は無視の有無、決めた行番号、規則の原文を示します。`git check-ignore -v` が 出力する 3 点に、除外された親ディレクトリを加えた形です。
4. 橙色の枠を確認します。`!` 規則がパスに一致していても、親ディレクトリがすでに除外されていて 効かない場合に出ます。否定規則が正しく見えるのに何も起きない典型的な理由です。
5. 一番下の死んだ規則の一覧を見ます。貼り付けたどのパスにも一致しなかった行で、パス一覧が代表的な ものであれば削除の候補です。

よくある質問

! を書いたのにファイルが戻ってこないのはなぜですか。

git がそのファイルを見ていないからです。ツリーをたどる途中でディレクトリが除外されて いると分かると、git はそこで止まって中へ降りません。したがってそのディレクトリの中身に 関する規則は評価すらされません。公式文書も「親ディレクトリが除外されているファイルを 再び含めることはできない」と明言しています。`logs/` と `!logs/important.log` を並べても ログは無視されたままで、本ツールは決定がディレクトリ規則から来たことを示します。直し方は ディレクトリではなく中身を除外することです。`logs/*` の次に `!logs/important.log` と 書きます。部分木ごと戻すなら `/logs/**`、`!/logs/keep/`、`!/logs/keep/**` の順が定石です。

build と /build は何が違いますか。

パターンにスラッシュが一つもなければ、あらゆる深さでパスの末尾の名前と比較されます。つまり `build` は /build も /src/build も /a/b/c/build も無視します。末尾以外の位置に スラッシュが一つでもあると、そのパターンは .gitignore の置かれたディレクトリに固定され、`/build` や `docs/output` はそこを起点にしか一致しません。ルートの .gitignore に単に `node_modules` と書くと入れ子のパッケージの node_modules まで隠れるのはこのためです。望みどおりのことが多い一方、意図して書いた人はまれです。「ここだけ」と言いたいときは 先頭にスラッシュを付けます。

`logs/` は logs という名前のファイルにも一致しますか。

いいえ。末尾のスラッシュはディレクトリだけを対象にするという意味なので、logs という 普通のファイルはそのまま残り、どの深さにあっても logs ディレクトリは中身ごと無視され ます。貼り付けたパス一覧に種別の情報がないことがここで効いてきます。git は実際の ファイルシステムを見て判断しますが、本ツールには教える必要があります。ディレクトリは `logs/`、ファイルは `logs` と書いてください。同じ文字列でもスラッシュの有無で逆の答えに なります。これはツールの癖ではなく、まだ存在しないパスに対して `git check-ignore` が 予想と違う答えを返す理由そのものです。

`**` の三つの形はそれぞれ何を意味しますか。

`**` はパス区間をまるごと占めるときだけ特別な意味を持ちます。先頭の `**/foo` はあらゆる 深さの foo に一致し、スラッシュなしのパターンがすでに行うことを明示的に書いた形です。末尾の `foo/**` は foo の中身すべてに一致しますが foo 自身には一致しません。前述の 再包含の手順が成り立つのはまさにこのためです。途中の `a/**/b` は a/b、a/x/b、a/x/y/b の ようにディレクトリ 0 個以上をまたいで一致します。それ以外の位置では単なる星です。`a**b` は `a*b` と同じで、星 1 個はスラッシュを越えないので `src/*.c` は src/main.c には 一致しても src/lib/main.c には一致しません。

規則は正しいのに git が変更を表示し続けます。

.gitignore は git がまだ追跡していないファイルにしか効きません。いったんコミットされた ファイルは、あとからパターンを足しても変わらず、変更が報告され続けコミットされ続けます。まず `git rm --cached パス` で追跡を外し（作業ディレクトリのファイルは残ります）、その 削除をコミットしてください。次のコミットからは無視規則が効きます。本ツールは `check-ignore` と同じく未追跡ファイルについての問いに答えるので、インデックスに入って いるパスは、ここで無視と出ても `git status` に現れ続けます。両者が食い違うときに最初に 確かめる点です。

.gitignore が複数あるとどれが勝ちますか。

git は決まった順序で複数の出所を読み、より具体的なものが勝ちます。まずコマンドラインの パターン、次に .gitignore ファイル群で、深いディレクトリのものが上位のものを上書きします。その次が共有されないリポジトリ固有の .git/info/exclude、最後が core.excludesFile が指す グローバルファイルです。一つのファイルの中では最後に一致した行が決めます。本ツールは .gitignore 一つだけを模しているので、結果が実際のリポジトリと違うなら、下位の .gitignore、info/exclude の項目、グローバルファイルが原因である可能性が高く、その場で `git check-ignore -v` を実行すれば出所の列がファイル名を教えてくれます。

関連ツール