.gitignoreが効かない？git check-ignoreで規則と追跡状態を調べる

.gitignoreにファイル名を追加したのに変更一覧から消えない。反対に、追加したいファイルがgit statusに出てこない。どちらも「無視の規則」だけを見ると、原因を取り違えやすい場面です。

まず追跡されているかと、どの規則に一致したかを順に調べると、不要な一括操作を避けられます。Git for Windowsを使っている場合は、PowerShellで目的のリポジトリを開いて進められます。以下のapp.logは、調べたいファイルのパスに置き換えて使えます。

対象ファイルの状態を見る

git status --short --ignored -- app.log

!! app.logなら無視されたファイル、?? app.logなら未追跡です。すでに追跡されていれば、追加や変更を表す別の状態になります。変更のない追跡済みファイルは、この一覧に出ないこともあります。

一致した規則と行番号を調べる

git check-ignore -v -- app.log

たとえば、リポジトリ直下の.gitignoreの1行目に*.logがあると、次のように表示されます。

.gitignore:1:*.log	app.log

左から規則を書いたファイル、行番号、パターン、調べたパスです。パターンとパスの間はタブで区切られます。規則は直下の.gitignoreだけでなく、配下の.gitignore、.git/info/exclude、ユーザー共通の除外ファイルにも置けます。表示された出所を見ると、別の設定を直していたことに気づけます。

通常の規則で何も表示されない場合は、そのパスに一致していない可能性があります。ただし、すでに追跡されているファイルも既定では表示されないので、次の確認を続けます。

すでに追跡されているかを調べる

git ls-files --error-unmatch -- app.log

インデックスにあるファイルならパスが表示され、終了コードは0になります。見つからなければエラーになり、終了コードは1です。未追跡のファイルを壊したという意味ではありません。

.gitignoreは、まだ追跡していないファイルを除外する仕組みです。すでにaddされているファイルへ規則を足しても、その追跡は解除されません。追跡中のパスについて「規則だけなら一致するか」を調べたい場合は、次の指定を使えます。

git check-ignore -v --no-index -- app.log

--no-indexは、この検査でインデックスの追跡状態を考慮しない指定です。ファイルをインデックスから削除する操作ではなく、実際の追跡状態も変わりません。ここで規則が表示されても、追跡中のファイルが無視されるようになったとは判断しないでください。

例外規則と親フォルダーも見る

たとえば.gitignoreに次の2行がある場合、logファイルを除外しつつ、keep.logだけを例外として含める指定になります。

*.log
!keep.log

git check-ignore -v -- keep.log

-vでは!keep.logという例外の規則も表示されます。「何か表示されたから除外されている」とは限らないので、パターン先頭の!とstatusの状態を合わせて読むのがポイントです。

親フォルダー自体が除外されていると、その中のファイルだけを!で戻すことはできません。たとえばlogs/で親を除外している場合と、logs/*で中身を対象にしている場合では、後続の例外の効き方が変わります。規則を直す前に、対象パスへ一致している行と、その親への指定を見直すと原因を絞れます。

診断結果に合わせて変更範囲を決める

未追跡なのに追加できなければ一致した除外規則を、追跡済みなのに変更一覧へ出るなら追跡状態を見直す、という順で進められます。表示を消すためだけに、リポジトリ全体を追跡し直す必要はありません。

追加した直後の内容をステージから外したい場合は、編集を残すgit restore –stagedの手順も参考になります。ただしステージ解除と、コミット済みファイルの追跡終了は同じ操作ではありません。.gitignoreを追加しても過去のコミットからファイルは消えないため、公開済みの秘密情報への対応は別途必要です。

コミット予定の内容が決まったら、git diff –checkによる空白検査で、ステージ前後の差分も確かめられます。

参考資料

• Git公式：git check-ignore
• Git公式：gitignore
• Git公式：git ls-files
• Git公式：git status