Validatore nomi branch git
Indichi il nome del branch e il suo modello: feature/ABC-123-add-login confrontato con type/ticket-description è valido e si divide in type feature, ticket ABC e description 123-add-login. Se non corrisponde, il messaggio riporta nome e modello insieme. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Branch
- feature/ABC-123-add-login
- Convenzione
- type/ticket-description
- Nomi dei componenti
- type, ticket, description
- Numero di componenti
- 3
I team che condividono un monorepo o un repository di prodotto di lunga durata di solito concordano una convenzione sui nomi dei branch affinché bot di review, script di release e link ai ticket possano analizzare ogni ref senza indovinare. Un pattern tipico è tipo barra ticket trattino descrizione—ad esempio feature/ABC-123-add-login—ma ogni organizzazione inventa i propri separatori e l’ordine dei componenti. Questo validatore di convenzione sui nomi dei branch git accetta la stringa del branch e il modello di convenzione, verifica che l’intero nome corrisponda dall’inizio alla fine e restituisce ogni componente nominato così che CI, hook e dashboard applichino la policy senza regex fragili monouso.
Come funziona il pattern di convenzione e cosa viene estratto
Una convenzione è un breve modello fatto di nomi di placeholder e separatori letterali. I placeholder sono identificatori ordinari: iniziano con una lettera o un underscore e proseguono con lettere, cifre o underscore. Tutto il resto nel modello è un separatore che deve comparire letteralmente nel nome del branch.
L’esempio classico type/ticket-description significa quindi tre componenti—type, ticket e description—uniti da una barra e poi da un trattino. Quando Lei invia il branch feature/ABC-add-login con quella convenzione, il validatore restituisce type uguale a feature, ticket uguale a ABC e description uguale a add-login. Il componente finale può contenere gli stessi caratteri dei separatori precedenti, così slug multi-parola come add-user-login restano dentro description invece di essere troncati al primo trattino.
I nomi dei componenti in una convenzione devono essere unici; il pattern deve iniziare e finire con un placeholder; placeholder e separatori devono alternarsi. Queste regole mantengono il matcher compilato deterministico ed evitano catture ambigue.
Casi d'uso
Gate CI per le pull request
Rifiuti i branch di PR che non corrispondono a type/ticket-description prima di build e test costosi.
Hook di pre-commit e onboarding
Insegni agli sviluppatori il pattern di nomenclatura della casa in locale con lo stesso matcher puro usato dal server.
Automazione ticket e changelog
Estragga i componenti ticket e type dal nome del branch per aggiornare i tracker e scegliere le sezioni del changelog.
Domande frequenti
Cosa succede se il nome del branch è vuoto?
Un nome di branch vuoto o solo spazi non viene mai accettato e non viene addebitato.
La parte description può contenere trattini?
Sì. Il placeholder finale cattura il suffisso rimanente, quindi add-user-login resta nell’ultimo componente quando il separatore precedente è un solo trattino.
Il validatore impone un elenco fisso di tipi di branch?
No. Controlla la struttura ed estrae i componenti. Applichi il proprio elenco consentito sul componente type se accetta solo feature, fix, chore ed etichette simili.
Perché il ticket risulta ABC e non ABC-123?
In type/ticket-description il ticket finisce al primo trattino, perché quel trattino è il separatore che precede la descrizione. Tutto ciò che segue, 123-add-login, appartiene all'ultima parte, che può contenere trattini propri.
Quali caratteri fanno fallire il nome di un branch?
Gli spazi, i punti consecutivi, la punteggiatura vietata da git e i caratteri di controllo. Anche un nome vuoto o fatto solo di spazi viene rifiutato, perché git non può creare un ramo senza nome.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"branch": "feature/ABC-123-add-login",
"convention": "type/ticket-description"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.git_branch_name_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
I nomi vuoti falliscono con invalid_input, così come caratteri di ref git non sicuri comuni quali spazi, punti consecutivi e punteggiatura vietata.
Come funziona il pattern di convenzione e cosa viene estratto
Se il branch non corrisponde all’intero pattern, l’attività fallisce con invalid_input e un messaggio che cita branch e convenzione così che gli sviluppatori correggano nome o policy a colpo d’occhio.
Contratto di input, controlli di sicurezza e forma della risposta
Anche i caratteri di controllo sono rifiutati. Le chiavi di output opzionali sono omesse anziché impostate a null. La validazione fallita non viene addebitata. Abbini la risposta al proprio livello di policy se serve un elenco consentito di valori di type come feature, fix, chore o release; questa capacità controlla la struttura ed estrae le parti, non codifica il vocabolario di una sola organizzazione. Invii con POST un corpo JSON con due stringhe obbligatorie: branch, il nome candidato del branch git, e convention, il modello di nomenclatura. Sono accettati alias per comodità—branch_name, name e ref per il campo branch; pattern, format e template per il campo convention—ma i nomi canonici compaiono nella documentazione e negli SDK. Entrambi i campi devono essere non vuoti dopo il rifiuto di soli spazi; un branch vuoto è sempre invalid_input perché git non può creare una ref di lunghezza zero e l’automazione che dimentica di passare il nome deve fallire in modo chiuso. In caso di successo il corpo include valid true, branch e convention ecoati, un oggetto components che associa ogni nome di placeholder al valore catturato, component_names nell’ordine del modello e component_count.
Dove un validatore di nomi di branch crea valore
I job di continuous integration usano un validatore di convenzione sui nomi dei branch git come primo passo di una pipeline così che le pull request aperte con nomi ad hoc non raggiungano mai fasi di build costose. L’automazione di release estrae il componente ticket per aprire o aggiornare issue del tracker, ed estrae il componente type per scegliere le sezioni del changelog senza hack fragili di sottostringhe. I siti di contenuti che si posizionano su validatore di convenzione nomi branch git beneficiano di un modulo live il cui percorso gratuito coincide byte per byte con il percorso di automazione a pagamento. I team di piattaforma che gestiscono molti repository pubblicano una sola stringa di convenzione nel portale sviluppatori e puntano ogni modello, bot e checklist a questo endpoint, così un cambio di policy è una sola modifica di stringa e non una caccia tra script shell. Poiché l’implementazione è pure parse di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello e senza rete in uscita.
Domande tecniche
Come valido un branch git rispetto a una convenzione di nomi?
Invii branch (ad esempio feature/ABC-add-login) e convention (ad esempio type/ticket-description). In caso di successo l’API restituisce valid true e una mappa components con ogni parte nominata.
Quanto costa il validatore di nomi di branch git?
Lo strumento nel browser è gratuito. Le richieste API usano il saldo KIT prepagato a $0.002 per chiamata riuscita; l’input non valido non viene addebitato.