Validador de nombres de ramas git
Indique el nombre de la rama y su plantilla: feature/ABC-123-add-login frente a type/ticket-description es válida y se separa en type feature, ticket ABC y description 123-add-login. Si no encaja, el mensaje muestra la rama y la plantilla juntas. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Rama
- feature/ABC-123-add-login
- Convención
- type/ticket-description
- Nombres de componentes
- type, ticket, description
- Número de componentes
- 3
Los equipos que comparten un monorepo o un repositorio de producto de larga vida suelen acordar una convención de nombres de ramas para que los bots de revisión, los scripts de release y los enlaces a tickets puedan interpretar cada ref sin adivinanzas humanas. Un patrón típico es tipo barra ticket guion descripción—por ejemplo feature/ABC-123-add-login—pero cada organización inventa sus propios separadores y el orden de los componentes. Este validador de convención de nombres de ramas git acepta la cadena de la rama y su plantilla de convención, comprueba que el nombre completo coincida de principio a fin y devuelve cada componente nombrado para que CI, hooks y paneles apliquen la política sin regex frágiles de un solo uso.
Cómo funciona el patrón de convención y qué se extrae
Una convención es una plantilla breve hecha de nombres de marcadores y separadores literales. Los marcadores son identificadores ordinarios: empiezan por letra o guion bajo y continúan con letras, dígitos o guiones bajos. Todo lo demás en la plantilla es un separador que debe aparecer literalmente en el nombre de la rama.
El ejemplo clásico type/ticket-description significa por tanto tres componentes—type, ticket y description—unidos por una barra y después un guion. Cuando usted envía la rama feature/ABC-add-login con esa convención, el validador devuelve type igual a feature, ticket igual a ABC y description igual a add-login. El componente final puede contener los mismos caracteres que separadores anteriores, de modo que slugs de varias palabras como add-user-login permanecen dentro de description en lugar de truncarse en el primer guion.
Los nombres de componente dentro de una convención deben ser únicos; el patrón debe empezar y terminar con un marcador; marcadores y separadores deben alternarse. Esas reglas mantienen el emparejador compilado determinista y evitan capturas ambiguas.
Contrato de entrada, comprobaciones de seguridad y forma de la respuesta
Antes del emparejamiento de patrón, el manejador aplica comprobaciones ligeras de seguridad de refs git: sin espacios, sin puntos consecutivos, sin dobles barras, sin secuencias arroba-llave, sin barras invertidas, sin barra o punto al inicio o al final, sin .lock final, y sin los caracteres ASCII tilde, circunflejo, dos puntos, interrogación, asterisco o corchete de apertura. También se rechazan caracteres de control. Las claves de salida opcionales se omiten en lugar de fijarse a null.
La validación fallida no se factura. Combine la respuesta con su propia capa de política si necesita una lista permitida de valores de type como feature, fix, chore o release; esta capacidad comprueba la estructura y extrae partes, no codifica el vocabulario de una sola organización.
Qué puede hacer con ella
Puerta CI para pull requests
Rechace ramas de PR que no coincidan con type/ticket-description antes de ejecutar compilaciones y pruebas costosas.
Hooks de pre-commit e incorporación
Enseñe a los desarrolladores el patrón de nomenclatura de la casa en local con el mismo emparejador puro que usa el servidor.
Automatización de tickets y changelog
Extraiga los componentes ticket y type del nombre de la rama para actualizar trackers y elegir secciones del changelog.
Preguntas frecuentes
¿Qué ocurre si el nombre de la rama está vacío?
Un nombre de rama vacío o solo con espacios nunca se acepta y no se factura.
¿Puede la parte description contener guiones?
Sí. El marcador final captura el sufijo restante, de modo que add-user-login permanece dentro del último componente cuando el separador anterior es un solo guion.
¿El validador impone una lista fija de tipos de rama?
No. Comprueba la estructura y extrae componentes. Aplique su propia lista permitida sobre el componente type si solo acepta feature, fix, chore y etiquetas similares.
¿Por qué el ticket sale como ABC y no como ABC-123?
En type/ticket-description el ticket termina en el primer guion, porque ese guion es el separador que precede a la descripción. Todo lo que viene después, 123-add-login, pertenece a la última parte, que admite sus propios guiones.
¿Qué caracteres hacen fallar el nombre de una rama?
Los espacios, los puntos consecutivos, los signos de puntuación prohibidos en git y los caracteres de control. Un nombre vacío o formado solo por espacios también se rechaza, porque git no puede crear una rama sin nombre.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"branch": "feature/ABC-123-add-login",
"convention": "type/ticket-description"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.git_branch_name_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Los nombres vacíos fallan con invalid_input, al igual que caracteres inseguros habituales en refs de git como espacios, puntos consecutivos y puntuación prohibida.
Cómo funciona el patrón de convención y qué se extrae
Si la rama no coincide con el patrón completo, la tarea falla con invalid_input y un mensaje que cita la rama y la convención para que los desarrolladores corrijan el nombre o la política de un vistazo.
Contrato de entrada, comprobaciones de seguridad y forma de la respuesta
Envíe por POST un cuerpo JSON con dos cadenas obligatorias: branch, el nombre candidato de la rama git, y convention, la plantilla de nomenclatura. Se aceptan alias por comodidad—branch_name, name y ref para el campo de la rama; pattern, format y template para el de la convención—pero los nombres canónicos aparecen en la documentación y los SDK. Ambos campos deben ser no vacíos tras rechazar solo espacios en blanco; una rama vacía es siempre invalid_input porque git no puede crear una ref de longitud cero y la automatización que olvida pasar el nombre debe fallar de forma cerrada. En el éxito el cuerpo incluye valid true, la rama y la convención ecoadas, un objeto components que mapea cada nombre de marcador a su valor capturado, component_names en el orden de la plantilla y component_count.
Dónde un validador de nombres de rama aporta valor real
Los trabajos de integración continua usan un validador de convención de nombres de ramas git como primer paso del pipeline para que las pull requests abiertas con nombres ad hoc no lleguen a etapas de compilación caras. La automatización de releases extrae el componente ticket para abrir o actualizar issues del tracker, y extrae el componente type para elegir secciones del changelog sin hacks frágiles de subcadenas. Los sitios de contenido que posicionan por validador de convención de nombres de rama git se benefician de un formulario en vivo cuya ruta gratuita coincide byte a byte con la ruta de automatización de pago. Los equipos de plataforma que operan muchos repositorios publican una sola cadena de convención en su portal de desarrolladores y apuntan cada plantilla, bot y lista de comprobación a este endpoint, de modo que un cambio de política es una sola edición de cadena y no una caza por scripts de shell. Como la implementación es pure parse de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo y sin red saliente.
Preguntas técnicas
¿Cómo valido una rama git frente a una convención de nombres?
Envíe branch (por ejemplo feature/ABC-add-login) y convention (por ejemplo type/ticket-description). Si tiene éxito, la API devuelve valid true y un mapa components con cada parte nombrada.
¿Cuánto cuesta el validador de nombres de ramas git?
La herramienta en el navegador es gratuita. Las solicitudes API usan saldo KIT prepago a $0.002 por llamada exitosa; la entrada inválida no se factura.