PFADE UND IGNORE-REGELN
Eine .gitignore im Stammverzeichnis und Kandidaten prüfen. Ein abschließendes / kennzeichnet ein Verzeichnis.
Regeln und Kandidaten bleiben in diesem Browser. Kein Repository wird gelesen oder geändert.
Geben Sie mindestens einen Kandidatenpfad ein.
Pfade gelten relativ zu dieser .gitignore. Verwenden Sie / und für Verzeichnisse ein abschließendes /. Absolute Pfade, Laufwerke, Backslashes, leere Segmente, . und .. sind ungültig. Leerzeichen bleiben erhalten.
Eine .gitignore im Stammverzeichnis, simulierte nicht verfolgte Pfade, UTF-8-Byteabgleich mit Groß-/Kleinschreibung. Keine untergeordneten Regeln, globalen Ausschlüsse, Index- oder Dateisystemdaten.
Bis zu 50 physische Regelzeilen und 200 nicht leere Kandidaten; 256 Zeichen je Regel, 512 je Pfad, 32 Segmente. Keine Steuerzeichen. Der Worker endet nach 2 Sekunden.
Ergebnisse sind veraltet oder werden berechnet.
Eine Ausnahme kann richtig aussehen und trotzdem wirkungslos bleiben: Schließt eine Regel das Elternverzeichnis aus, erreicht Git die Datei nicht. Der Gitignore-Tester nennt das blockierende Verzeichnis und die entscheidende Zeile. Damit lässt sich zwischen einer passenden Ausnahme und einer tatsächlich wirksamen Ausnahme unterscheiden.
Zum Prüfen neuer gitignore-Regeln gehören auch Pfade, die erhalten bleiben sollen. Vergleichen Sie beide Gruppen, bevor Sie die Datei im Repository ändern. Der Verlauf zeigt nach jeder hinzugefügten Zeile das Ergebnis aller bis dahin eingelesenen Regeln.
build/ schließt den Ordner selbst aus. !build/keep.txt kann die darin liegende Datei deshalb nicht zurückholen. cache/* lässt dagegen cache/ erreichbar, sodass !cache/keep.txt wirken kann. Der Gitignore-Tester zeigt den ausgeschlossenen Vorfahren an, statt jede Negation als erfolgreiche Ausnahme zu behandeln.
Ausschluss, Ausnahme und erneuter Ausschluss können denselben Pfad mehrfach verändern. Im Verlauf bleiben Kommentare und Leerzeilen an ihrem Platz. Vergleichen Sie die entscheidende Zeile vor und nach einer Änderung: Die neu hinzugefügte Zeile muss nicht diejenige sein, die das Ergebnis bestimmt.
Geben Sie Pfade relativ zum Verzeichnis der .gitignore an: build/ für den Ordner, build für eine Datei. Ein führendes / verankert ein Muster, ist aber bei Kandidaten ungültig. Leerzeichen in Kandidaten bleiben erhalten und werden nicht zur vermeintlichen Korrektur entfernt.
Öffnen Sie den Verlauf eines Ergebnisses. Ist ein Elternordner ausgeschlossen, muss er zuerst wieder erreichbar werden; alternativ kann cache/* nur dessen Inhalt ausschließen. Jeder Schritt bewertet den gesamten bisherigen Regelsatz erneut. Er behauptet keinen direkten Treffer der gerade hinzugefügten Zeile.
Die Automatik wartet nach Änderungen 350 ms. Schalten Sie sie aus, um per Schaltfläche oder Ctrl/Cmd+Enter zu prüfen. Bearbeitungen sperren sofort den Export alter Ergebnisse. Beispiel und Leeren benötigen eine Vorschau mit Anwendung; Rückgängig stellt Eingaben und Ergebnisse gemeinsam wieder her.
Die öffentlichen APIs von ignore 7.0.9 verarbeiten *, ?, Zeichenbereiche und **. Der Abgleich erfolgt mit Groß-/Kleinschreibung auf UTF-8-Bytes. Ein ? steht daher für ein Byte und nicht für ein ganzes Mehrbytezeichen. Klammerexpansion und reguläre Ausdrücke sind keine zusätzlichen Modi.
Kommentare und Leerzeilen verändern die ursprüngliche Nummerierung nicht. Für jeden erreichbaren Pfad entscheidet das letzte passende Muster über Ausschluss oder Wiederaufnahme. Auch wiederholte positive Regeln zeigen deshalb die letzte passende Zeile. Eine vom Elternordner geerbte Entscheidung wird gesondert kenntlich gemacht.
JSON enthält Originalpfade, Regeltext und alle Zwischenstände. TSV fasst Verzeichnisstatus, Ausschluss, entscheidende Zeile, Muster und blockierenden Elternpfad zusammen. Formelähnliche Zellen erhalten ein schützendes Apostroph. Der Export enthält alle Kandidaten, auch wenn gerade nur die ersten 50 sichtbar sind.
Ein ausgeschlossener Elternordner verhindert den Zugriff auf seine Dateien. Eine Ausnahme für die Datei allein öffnet diesen Ordner nicht. Nehmen Sie zuerst den Ordner wieder auf oder schließen Sie mit build/* nur dessen Inhalt aus. Der Gitignore-Tester nennt den blockierenden Elternpfad im Ergebnis.
Für gemeinsame Projektregeln liegt sie meist im Stammverzeichnis. Git erlaubt zusätzliche Dateien in Unterverzeichnissen, deren Regeln ab dort gelten. Diese Simulation verwendet genau eine Regeldatei als Basis; sämtliche Kandidaten müssen relativ zu deren Verzeichnis angegeben werden.
Neue Ignore-Regeln beenden die Verfolgung nicht. Prüfen Sie zuerst den Index im Repository. Mit git rm --cached pfad können Sie einen ausgewählten Pfad aus dem Index nehmen und die Arbeitskopie behalten; prüfen Sie die vorgemerkte Änderung vor dem Commit. Dieser Tester verändert den Index nicht.
Ja, wenn sie die gemeinsamen Regeln des Projekts beschreibt. Dann erhalten andere Mitwirkende dieselben Muster beim Klonen. Persönliche Ausschlüsse können in .git/info/exclude stehen. Das Testergebnis ist ein Bericht über Ihre Kandidaten und schreibt selbst keine Regeldatei ins Repository.
Sie eignet sich etwa für persönliche Editor- oder Betriebssystemdateien, die Sie in vielen Projekten ausschließen möchten. Git bindet sie über core.excludesFile ein. Hier wird sie nicht gelesen. Weicht die Simulation vom Repository ab, prüfen Sie dort auch globale und lokale Ausschlussquellen.
Haben Sie einen weiteren Pfadfall gefunden?
Geben Sie dem Gitignore-Tester einen Pfad, der verschwinden soll, und einen, der erhalten bleiben muss. Bei einer wirkungslosen Ausnahme hilft auch der Elternordner selbst als Kandidat.
Bewahren Sie den Verlauf für die Prüfung auf und bestätigen Sie das Verhalten anschließend mit Git im tatsächlichen Repository.