ForHosting KIT · Entwickler-Tools

Prüfen Sie einen Pfad mit .gitignore-Mustern

Erfahren Sie, ob Git eine Datei ignorieren würde und welche Regel entscheidet: logs/build.log wird wegen *.log ignoriert, der zweiten Regel der Liste, und eine spätere Regel wie !important.log kann eine frühere aufheben. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Muster: dist/, *.log, !important.log, secrets/**
Pfad: logs/build.log

Erhalten Sie

Passendes Muster: *.log
Passender Index: 1

Prüfen Sie einen repositoryrelativen Pfad anhand einer geordneten Liste von .gitignore-Mustern, ohne ein temporäres Repository anzulegen oder Git aufzurufen. Das Ergebnis zeigt, ob der Pfad ignoriert wird, und nennt bei einer Übereinstimmung das letzte entscheidende Muster sowie dessen nullbasierte Position. Die Prüfung unterstützt Kommentare, Escape-Zeichen, an der Wurzel verankerte Regeln, Verzeichnisregeln, Platzhalter, Zeichenklassen, rekursive Doppelsterne und Negationen. Fehlerhafte Muster werden abgelehnt, statt sie unbemerkt als harmlose Literale zu behandeln.

Übergeben Sie die Regeln in ihrer echten Reihenfolge

Eine .gitignore-Datei ist nicht nur eine Sammlung voneinander unabhängiger Globs. Git wertet die Regeln der Reihe nach aus, und eine später passende Regel kann die Entscheidung einer früheren Regel ändern. Übergeben Sie die Muster genau in der Reihenfolge, in der sie in der betreffenden Ignore-Datei stehen.

Normale passende Muster markieren den Pfad als ignoriert; eine Regel mit einem nicht maskierten Ausrufezeichen am Anfang hebt diese Entscheidung dagegen auf. Leerzeilen und Zeilen, die mit einem nicht maskierten Rautezeichen beginnen, gelten wie in einer gewöhnlichen Ignore-Datei nicht als Regeln. Die Antwort enthält das letzte passende Muster und seinen nullbasierten Array-Index.

Dadurch lässt sich ein überraschendes Ergebnis in einem Build-Werkzeug oder Konfigurationseditor nachvollziehbar erklären. Pfade müssen relativ zur Repository-Wurzel angegeben werden und Schrägstriche verwenden. Ein stabiler, normalisierter Pfad verhindert unterschiedliche Antworten durch absolute Präfixe, übergeordnete Verzeichnissegmente oder betriebssystemspezifische Trennzeichen.

Verstehen Sie das unterstützte Musterverhalten

Ein einzelner Stern steht für beliebig viele Zeichen innerhalb genau eines Pfadsegments, ein Fragezeichen für ein einzelnes Zeichen außer dem Schrägstrich. Ein führender Schrägstrich verankert die Regel an der Repository-Wurzel. Ein Muster ohne Schrägstrich kann einen Namen in jeder Tiefe treffen.

Bezeichnet dieser Name im übergebenen Pfad ein Verzeichnis, wird auch dessen gesamter Inhalt erfasst. Ein abschließender Schrägstrich kennzeichnet eine Verzeichnisregel. Da die Prüfung nur einen Pfad und keinen Dateisystembaum erhält, entscheidet sie anhand des Pfadtexts und seiner Vorfahren; sie ermittelt nicht, ob die letzte Komponente tatsächlich als Datei oder Verzeichnis existiert.

Maskierte Raute- und Ausrufezeichen am Anfang bleiben literal, nicht maskierte Leerzeichen am Ende werden gemäß den Konventionen entfernt.

Finden Sie Konfigurationsfehler durch Validierung

Glob-Fehler bleiben leicht unbemerkt, wenn eine Ignore-Datei durch viele kleine Änderungen wächst. Diese Prüfung meldet eine ungültige Eingabe bei fehlerhaften Strukturen wie einer nicht geschlossenen oder leeren Zeichenklasse, einem unvollständigen Escape oder einem Negationszeichen ohne Ausdruck. Anzahl und Länge der Muster sind ebenfalls begrenzt, damit ein Validierungsendpunkt keine unbegrenzte Kompilierungsarbeit ausführen kann.

Eine erfolgreiche Antwort verändert die Regeln nicht und hängt weder von einem Netzwerkdienst noch von Uhrzeit, Zufall, Repository-Inhalt oder Host-Betriebssystem ab. Damit eignet sich die Funktion für deterministische Prüfungen vor Commits, Webformulare, IDE-Diagnosen und Richtlinientests in CI.

Anwendungsfälle

Fehlende Build-Eingabe erklären

Prüfen Sie den fehlenden Pfad gegen die Projektregeln und zeigen Sie die zuletzt für den Ausschluss verantwortliche Regel.

Editor für Ignore-Regeln validieren

Zeigen Sie vor dem Speichern, wie eine verschobene Regel oder eine neue Negation das Ergebnis verändert.

Häufige Fragen

Spielt die Reihenfolge der Regeln eine Rolle?

Ja. Jede Regel wird der Reihe nach ausgewertet, und die letzte Übereinstimmung entscheidet, ob der Pfad ignoriert wird.

Werden negierte Muster unterstützt?

Ja. Ein führendes, nicht maskiertes Ausrufezeichen erzeugt eine negierte Regel, die einen zuvor ignorierten Pfad wieder sichtbar machen kann.

Liest die Prüfung mein Repository oder die globale Git-Konfiguration?

Nein. Sie verwendet ausschließlich die Muster und den repositoryrelativen Pfad aus der Anfrage.

Können Muster mehrere Verzeichnisse überspannen?

Ja. Doppelstern-Muster dürfen Verzeichnisgrenzen überschreiten, ein einzelner Stern bleibt dagegen in einem Pfadsegment.

Wie erkenne ich, welche Regel das Ergebnis bestimmt hat?

Die Antwort nennt die letzte passende Regel und ihre Position in Ihrer Liste, gezählt ab 0. Im Beispiel wird logs/build.log durch *.log an Position 1 ignoriert, sodass sich ein überraschendes Ergebnis leicht erklären lässt.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/dev2/gitignore-check-path

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/dev2/gitignore-check-path \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}'

const res = await fetch("https://api.kit.forhosting.com/dev2/gitignore-check-path", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "patterns": [
      "dist/",
      "*.log",
      "!important.log"
    ],
    "path": "logs/build.log"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev2/gitignore-check-path",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "patterns": [
        "dist/",
        "*.log",
        "!important.log"
    ],
    "path": "logs/build.log"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/gitignore-check-path", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"patterns":["dist/","*.log","!important.log"],"path":"logs/build.log"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/gitignore-check-path", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "patterns": [
    "dist/",
    "*.log",
    "!important.log"
  ],
  "path": "logs/build.log"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.gitignore_check_path",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Limits

`max_patterns`	1000
`max_pattern_chars`	1024
`max_path_chars`	4096

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Verstehen Sie das unterstützte Musterverhalten

Zeichenklassen wie `[0-9]` wählen ein Zeichen aus einer Menge oder einem Bereich. Ein Doppelstern darf Verzeichnisgrenzen überschreiten; deshalb erfasst `docs/**/draft*.md` Entwürfe direkt unter `docs` ebenso wie in tieferen Ordnern.

Finden Sie Konfigurationsfehler durch Validierung

Bewahren Sie bei einer Automatisierung `matching_pattern` zusammen mit der booleschen Entscheidung auf: Die Erklärung ist oft nützlicher als der Wahrheitswert allein. Die Browserversion nutzt denselben reinen Solver wie die API; für eine API-Anfrage gilt der veröffentlichte Grundpreis von $0.002.

Integrationsbeispiele

Repository-Richtlinien in CI durchsetzen

Stellen Sie sicher, dass erzeugte Artefakte ignoriert werden, erforderliche Fixtures und Quelldateien aber verfolgbar bleiben.

Technische Fragen

Was geschieht bei einem fehlerhaften Muster?

Die Anfrage schlägt mit invalid_input fehl und nennt die Position des Musters sowie den strukturellen Fehler.

Was kostet eine API-Anfrage?

Der Grundpreis beträgt $0.002 pro Anfrage. Derselbe deterministische Solver steht auch im Browser bereit.

Vollständige KIT-Dokumentation lesen →

Prüfen Sie einen Pfad mit .gitignore-Mustern

Im Browser ausführen – kostenlos

Rechenbeispiel

Übergeben Sie die Regeln in ihrer echten Reihenfolge

Verstehen Sie das unterstützte Musterverhalten

Finden Sie Konfigurationsfehler durch Validierung

Anwendungsfälle

Fehlende Build-Eingabe erklären

Editor für Ignore-Regeln validieren

Häufige Fragen

Verwandte Tools

Für Entwickler — API-Zugang

Endpunkt

Aufruf aus Ihrem Stack

Beispiel-Anfrage

Beispiel-Antwort

Preis

Limits

Fehler

Technische Hinweise

Verstehen Sie das unterstützte Musterverhalten

Finden Sie Konfigurationsfehler durch Validierung

Integrationsbeispiele

Repository-Richtlinien in CI durchsetzen

Technische Fragen

danke