.gitignoreGenerator
guide

Warum wird das ignoriert? Fehlersuche mit git check-ignore

So finden Sie mit git check-ignore -v, git status --ignored und git ls-files heraus, welche Regel eine Datei ignoriert, und prüfen sieben häufige Ursachen, wenn eine Regel nicht greift.

Je mehr Regeln es gibt, desto öfter stellt sich die Frage: „Warum sehe ich diese Datei nicht?“ oder „Warum taucht sie immer noch auf?“ git hat einen Befehl, der darauf antwortet.

git check-ignore -v

git check-ignore -v logs/app.log src/build/keep.txt

Die Ausgabe hat das Format Quelle:Zeilennummer:Muster<Tab>Pfad.

.gitignore:3:*.log	logs/app.log

Um auch nicht passende Pfade zu sehen, kombinieren Sie mit --non-matching (-n).

Verfolgte Dateien: --no-index

Auf bereits verfolgte Dateien werden Ausschlussregeln nicht angewendet, daher gibt check-ignore standardmäßig auch nichts aus. Wollen Sie nur wissen, ob eine Regel auf die Datei passt, fügen Sie --no-index hinzu.

$ git check-ignore -v app.log            # verfolgt, daher keine Ausgabe
$ git check-ignore -v --no-index app.log
.gitignore:3:*.log	app.log

Liste der ignorierten Dateien anzeigen

# Ignorierte Einträge zusammen mit dem Status anzeigen (Markierung !!)
git status --ignored --short

# Alle ignorierten Dateien einzeln auflisten
git ls-files --others --ignored --exclude-standard

# Verfolgte Dateien, auf die Ausschlussregeln passen
git ls-files -ci --exclude-standard

git status --ignored zeigt ein vollständig ignoriertes Verzeichnis als einen Eintrag wie !! logs/. Für eine Anzeige Datei für Datei verwenden Sie ls-files.

Häufige Gründe, warum eine Regel nicht greift

  1. Die Datei wird bereits verfolgt. Das ist der häufigste Grund. Gibt git ls-files <Pfad> etwas aus, wird sie verfolgt. Beenden Sie das Tracking mit git rm --cached.
  2. Das Elternverzeichnis ist ausgeschlossen. Ist dir/ ignoriert, bleibt !dir/file wirkungslos. Ändern Sie es in dir/*.
  3. Die Reihenfolge ist vertauscht. Folgt auf eine Negationsregel erneut eine breitere Regel, gewinnt diese. Die Zeilennummer in check-ignore -v zeigt das sofort.
  4. Nachgestellte Leerzeichen. Das Leerzeichen am Ende von *.log wird entfernt; Leerzeichen vor dem Muster oder unsichtbare Zeichen wie ein geschütztes oder ideografisches Leerzeichen bleiben dagegen Teil des Musters.
  5. Richtung des Schrägstrichs. gitignore verwendet auch unter Windows nur / als Pfadtrenner. In build\output wird der Backslash als Escape-Zeichen gedeutet, sodass die Regel nicht wie beabsichtigt wirkt.
  6. Missverständnis bei der Verankerung. config/local.json passt wegen des Schrägstrichs in der Mitte nur auf config im Wurzelverzeichnis. Für jede Tiefe verwenden Sie **/config/local.json.
  7. Groß-/Kleinschreibung. In Umgebungen mit core.ignorecase auf false (meist Linux) sind *.JPG und *.jpg verschieden. Unter macOS oder Windows angelegte Repositorys stehen meist auf true, sodass eine Regel lokal funktionieren und in der CI scheitern kann.

Vorab im Browser prüfen

Wenn Sie Regeln vor dem Einsatz im Repository ändern und die Ergebnisse vergleichen möchten, ist der Tab Mustertest dieser Website praktisch. Fügen Sie Regeln und eine Pfadliste ein, und für jeden Pfad werden das Ergebnis, die entscheidende Regel (mit Zeilennummer) sowie Fälle angezeigt, in denen ein Elternverzeichnis den Ausschluss verursacht. Als Pfadliste können Sie die Ausgabe von git ls-files oder find . -type f direkt verwenden. Das endgültige Ergebnis unter Einbeziehung der .gitignore in Unterverzeichnissen und der globalen Einstellung prüfen Sie aber im Repository mit git check-ignore -v.

Quellen

← ZurückBereits committete Dateien mit .gitignore ignorieren