Git-Branch-Namenskonvention prüfen
Geben Sie den Branch-Namen und Ihre Vorlage an: feature/ABC-123-add-login gegen type/ticket-description ist gültig und zerfällt in type feature, ticket ABC und description 123-add-login. Passt der Name nicht, nennt die Meldung Name und Vorlage nebeneinander. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Branch
- feature/ABC-123-add-login
- Konvention
- type/ticket-description
- Komponentennamen
- type, ticket, description
- Anzahl der Komponenten
- 3
Teams, die ein Monorepo oder ein langlebiges Produkt-Repository teilen, vereinbaren in der Regel eine Namenskonvention für Branches, damit Review-Bots, Release-Skripte und Ticket-Links jede Ref ohne menschliches Raten auswerten können. Ein typisches Muster sieht aus wie Typ Schrägstrich Ticket Bindestrich Beschreibung—zum Beispiel feature/ABC-123-add-login—doch jede Organisation erfindet eigene Trennzeichen und die Reihenfolge der Komponenten. Dieser Validator für Git-Branch-Namenskonventionen nimmt den Branch-String und Ihre Konventionsvorlage entgegen, prüft, dass der gesamte Name von Anfang bis Ende passt, und liefert jede benannte Komponente zurück, damit CI, Hooks und Dashboards die Richtlinie ohne brüchige Einmal-Regexen durchsetzen.
So funktioniert das Konventionsmuster und was extrahiert wird
Eine Konvention ist eine kurze Vorlage aus Platzhalternamen und wörtlichen Trennzeichen. Platzhalter sind gewöhnliche Bezeichner: sie beginnen mit einem Buchstaben oder Unterstrich und setzen sich mit Buchstaben, Ziffern oder Unterstrichen fort. Alles Übrige in der Vorlage ist ein Trennzeichen, das wörtlich im Branch-Namen vorkommen muss.
Das klassische Beispiel type/ticket-description bedeutet daher drei Komponenten—type, ticket und description—verbunden durch einen Schrägstrich und danach einen Bindestrich. Wenn Sie den Branch feature/ABC-add-login mit dieser Konvention senden, liefert der Validator type gleich feature, ticket gleich ABC und description gleich add-login. Die letzte Komponente darf dieselben Zeichen wie frühere Trennzeichen enthalten, sodass mehrteilige Slugs wie add-user-login in description bleiben statt am ersten Bindestrich abgeschnitten zu werden.
Komponentennamen innerhalb einer Konvention müssen eindeutig sein; das Muster muss mit einem Platzhalter beginnen und enden; Platzhalter und Trennzeichen müssen sich abwechseln. Diese Regeln halten den kompilierten Matcher deterministisch und vermeiden mehrdeutige Captures.
Anwendungsfälle
CI-Gate für Pull Requests
Lehnen Sie PR-Branches ab, die nicht type/ticket-description entsprechen, bevor teure Builds und Tests laufen.
Pre-Commit- und Onboarding-Hooks
Vermitteln Sie Entwicklern das hausinterne Namensmuster lokal mit demselben reinen Matcher wie auf dem Server.
Ticket- und Changelog-Automatisierung
Extrahieren Sie ticket- und type-Komponenten aus dem Branch-Namen, um Tracker zu aktualisieren und Changelog-Abschnitte zu wählen.
Häufige Fragen
Was passiert, wenn der Branch-Name leer ist?
Ein leerer oder nur aus Leerzeichen bestehender Branch-Name wird nie akzeptiert und nicht abgerechnet.
Darf der description-Teil Bindestriche enthalten?
Ja. Der letzte Platzhalter erfasst das verbleibende Suffix, sodass add-user-login im letzten Bestandteil bleibt, wenn das davor stehende Trennzeichen ein einzelner Bindestrich ist.
Erzwingt der Validator eine feste Liste von Branch-Typen?
Nein. Er prüft die Struktur und extrahiert Komponenten. Wenden Sie Ihre eigene Allow-Liste auf die type-Komponente an, wenn Sie nur feature, fix, chore und ähnliche Labels akzeptieren.
Warum ergibt das Ticket ABC und nicht ABC-123?
In type/ticket-description endet das Ticket am ersten Bindestrich, denn dieser Bindestrich trennt es von der Beschreibung. Alles danach, also 123-add-login, gehört zum letzten Teil, der eigene Bindestriche enthalten darf.
Welche Zeichen lassen einen Branch-Namen scheitern?
Leerzeichen, aufeinanderfolgende Punkte, von git verbotene Satzzeichen und Steuerzeichen. Auch ein leerer Name oder einer nur aus Leerzeichen wird abgelehnt, weil git keinen Branch ohne Namen anlegen kann.
Verwandte Tools
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
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/dev/git-branch-name-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"branch":"feature/ABC-123-add-login","convention":"type/ticket-description"}'const res = await fetch("https://api.kit.forhosting.com/dev/git-branch-name-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"branch": "feature/ABC-123-add-login",
"convention": "type/ticket-description"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/git-branch-name-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"branch": "feature/ABC-123-add-login",
"convention": "type/ticket-description"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/git-branch-name-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"branch":"feature/ABC-123-add-login","convention":"type/ticket-description"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"branch":"feature/ABC-123-add-login","convention":"type/ticket-description"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/git-branch-name-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"branch": "feature/ABC-123-add-login",
"convention": "type/ticket-description"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.git_branch_name_validate",
"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
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
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
Leere Namen scheitern mit invalid_input, ebenso gängige unsichere Git-Ref-Zeichen wie Leerzeichen, aufeinanderfolgende Punkte und verbotene Satzzeichen.
So funktioniert das Konventionsmuster und was extrahiert wird
Passt der Branch nicht zum gesamten Muster, scheitert die Aufgabe mit invalid_input und einer Meldung, die Branch und Konvention zitiert, damit Entwickler Name oder Richtlinie auf einen Blick korrigieren können.
Eingabevertrag, Sicherheitsprüfungen und Antwortform
Steuerzeichen werden ebenfalls abgelehnt. Optionale Ausgabeschlüssel werden weggelassen statt auf null gesetzt. Fehlgeschlagene Validierung wird nicht abgerechnet. Kombinieren Sie die Antwort mit Ihrer eigenen Policy-Schicht, wenn Sie eine Allow-Liste von type-Werten wie feature, fix, chore oder release brauchen; diese Fähigkeit prüft Struktur und extrahiert Teile, sie hartcodiert nicht das Vokabular einer einzelnen Organisation. Senden Sie per POST einen JSON-Body mit zwei Pflichtstrings: branch, den Kandidaten-Git-Branch-Namen, und convention, die Namensvorlage. Aliase werden der Bequemlichkeit halber akzeptiert—branch_name, name und ref für das Branch-Feld; pattern, format und template für das Konventionsfeld—die kanonischen Namen erscheinen jedoch in Dokumentation und SDKs. Beide Felder müssen nach Ablehnung reiner Leerzeichen nicht leer sein; ein leerer Branch ist stets invalid_input, weil Git keine Ref der Länge null anlegen kann und Automatisierung, die den Namen vergisst, geschlossen scheitern soll. Bei Erfolg enthält der Body valid true, den zurückgespiegelten Branch und die Konvention, ein components-Objekt, das jeden Platzhalternamen dem erfassten Wert zuordnet, component_names in Vorlagenreihenfolge und component_count.
Wo ein Branch-Namensvalidator echten Nutzen stiftet
Continuous-Integration-Jobs nutzen einen Validator für Git-Branch-Namenskonventionen als ersten Schritt einer Pipeline, damit Pull Requests mit Ad-hoc-Namen teure Build-Stufen nie erreichen. Release-Automatisierung extrahiert die ticket-Komponente, um Tracker-Issues zu öffnen oder zu aktualisieren, und die type-Komponente, um Changelog-Abschnitte ohne brüchige Teilstring-Hacks zu wählen. Content-Sites, die für Validator für Git-Branch-Namenskonventionen ranken, profitieren von einem Live-Formular, dessen kostenloser Pfad bytegenau dem bezahlten Automatisierungspfad entspricht. Plattformteams mit vielen Repositories veröffentlichen eine einzige Konventionszeichenkette im Entwicklerportal und richten jede Vorlage, jeden Bot und jede Checkliste auf diesen Endpoint, sodass eine Policy-Änderung eine einzige String-Bearbeitung ist und keine Jagd durch Shell-Skripte. Weil die Implementierung pure parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz.
Technische Fragen
Wie validiere ich einen Git-Branch gegen eine Namenskonvention?
Senden Sie branch (zum Beispiel feature/ABC-add-login) und convention (zum Beispiel type/ticket-description). Bei Erfolg liefert die API valid true und eine components-Map mit jedem benannten Teil.
Was kostet der Validator für Git-Branch-Namen?
Das Browser-Werkzeug ist kostenlos. API-Anfragen nutzen das vorausbezahlte KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingaben werden nicht abgerechnet.