.gitignore に書いたのに、ファイルがGitの管理対象から消えない。そんなときは、パターンを書き足す前に 「どの除外ルールに一致するか」と「すでに追跡されていないか」 を確認します。
初心者向けに、複雑なパターンや優先順位の説明は省略します。git add を使ったことがある方向けの、既存ファイルを変更せずに原因を調べる小ネタです。コマンドはリポジトリのルートで実行します。
どのファイルの何行目が効いているかを確認する
ルートの .gitignore に、次の1行があるとします。
*.log
まだ git add していない build.log がある状態で、次を実行します。
git check-ignore -v -- build.log
確認用のリポジトリでは、次の出力になりました。
.gitignore:1:*.log build.log
読みやすいように区切りのタブを空白に置き換えています。.gitignore の1行目にある *.log が build.log に一致している、という意味です。
-v は詳細表示のオプションです。ファイル名だけでなく、適用されたルールの場所と内容まで確認できます。ルールが .git/info/exclude や個人設定の除外ファイルにある場合も、出力された場所を手掛かりにできます。
なお、表示されたパターンが ! で始まる場合は、除外を取り消す例外ルールです。出力があることだけで「無視されている」と判断せず、パターンまで読みます。
何も出ないときは、すでに追跡されていないかを見る
同じ *.log があるのに、次のコマンドで何も出ない場合があります。
git check-ignore -v -- tracked.log
今回の確認では、tracked.log を先にコミットしておくと、この状態になりました。
.gitignore は、意図的に追跡しないファイルを除外するための設定です。すでにGitが追跡しているファイルには効きません。 git check-ignore も、既定では追跡済みファイルを表示しません。
追跡されているかは、次で確認できます。
git ls-files --error-unmatch -- tracked.log
今回の例では tracked.log が表示され、終了コードは 0 でした。git ls-files は、Gitのインデックス（次のコミットへ登録する内容）にあるファイルを確認するコマンドです。--error-unmatch を付けると、指定したファイルがインデックスになければ終了コード 1 になります。
未追跡でも、どのルールにも一致しなければ git check-ignore -v は無出力になります。無出力という結果だけでは、この2つを区別できません。
パターン自体を確かめるなら --no-index
追跡済みであることが分かったうえで、「このパターンはファイル名に一致するのか」だけを確認するには、--no-index を使います。
git check-ignore -v --no-index -- tracked.log
今回の出力は次のとおりです。
.gitignore:1:*.log tracked.log
ここでも区切りのタブを空白に置き換えています。この結果から、パターンは一致していると確認できます。
ただし、--no-index は追跡状態を考慮せずに除外ルールを調べるオプションです。追跡を解除したり、ファイルを削除したりする操作ではありません。実行後も tracked.log は追跡されたままです。
.gitignore が効かないと感じたら、git check-ignore -v でルールを読み、無出力なら git ls-files で追跡状態を確認する。これで、除外パターンを直すべきか、追跡対象を見直すべきかを判断しやすくなります。
確認環境・参考資料
2026年10月、Windows／PowerShell／Git 2.54.0.windows.1 の一時リポジトリで確認しました。ルートの .gitignore に *.log を指定し、未追跡の build.log と、ルール追加前にコミットした tracked.log で、上記の出力と追跡状態を確認しています。