Escribir un mensaje de commit
Dentro de seis meses, 'arreglos varios' no le dice nada a quien ejecuta git blame sobre qué cambió realmente ni por qué. Este endpoint lee un diff y devuelve un mensaje correctamente estructurado en formato Conventional Commits, del tipo que deja contento tanto a un generador de changelog como a un compañero de equipo en el futuro.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
Por qué el mensaje importa más de lo que parece
Un mensaje de commit se lee muchas más veces de las que se escribe: lo lee un compañero de equipo revisando git log en busca de contexto, lo lee una herramienta de changelog que decide si un cambio es una funcionalidad o una corrección, lo lee quien ejecuta git blame sobre una línea rota dos años después tratando de entender la intención, no solo el contenido del diff. Un mensaje vago borra todo ese contexto justo en el momento en que era más barato capturarlo, cuando el cambio todavía estaba fresco en la cabeza de alguien.
Qué envía
Envía un diff, ya sean los cambios en stage o un rango específico de commits, y la API lee las adiciones y eliminaciones reales en vez de pedirle que describa lo que hizo. Esto importa porque las personas desarrolladoras son notoriamente malas resumiendo con precisión sus propios cambios bajo presión de tiempo, y un mensaje generado a partir del diff mismo refleja lo que realmente cambió, no lo que alguien recuerda haber cambiado.
La estructura de Conventional Commits
Conventional Commits es una especificación ligera que estructura un mensaje como un tipo, un alcance opcional y una descripción breve, por ejemplo fix(auth): handle expired refresh tokens, y existe porque las herramientas dependen de esa estructura: semantic-release y herramientas similares analizan el tipo para decidir si una versión es un parche, un cambio menor o uno mayor, y los generadores de changelog agrupan entradas por tipo automáticamente. La respuesta sigue esa convención, eligiendo el tipo, feat, fix, refactor, chore, docs, test y demás, según lo que el diff realmente hace, más un alcance inferido a partir de los archivos modificados.
Dónde encaja en su flujo de trabajo
La integración natural es un hook de pre-commit o prepare-commit-msg que envía el diff en stage y precarga el editor de commit con un mensaje sugerido que el desarrollador puede aceptar tal cual o editar en segundos. También encaja en un escenario de limpieza por lotes: reescribir una serie de mensajes vagos en una rama de funcionalidad antes de aplastarla e integrarla, para que el historial final sea claro.
Lo que no va a inventar
El mensaje describe qué cambia el diff, no por qué se tomó una decisión de negocio ni qué ticket lo originó, porque ese contexto no existe en el código en sí. Si quiere una referencia a un ticket o un cuerpo más largo explicando la motivación, agréguelo después de la línea de resumen generada en vez de esperar que la API adivine un contexto que nunca se le dio.
Qué puede hacer con ella
Automatización con hook de pre-commit
Un hook prepare-commit-msg envía el diff en stage y precarga un mensaje en formato Conventional Commits, de modo que el desarrollador solo revisa y confirma en vez de redactarlo desde cero.
Limpiar una rama de funcionalidad antes de integrarla
Un desarrollador con quince commits de tipo 'wip' regenera un mensaje claro para cada uno antes de un rebase interactivo, para que el historial aplastado explique realmente el cambio.
Mantener un historial listo para changelog
Un equipo que usa semantic-release genera cada mensaje de commit a través del endpoint para garantizar que el prefijo de tipo sea correcto y el incremento de versión automático sea el adecuado.
Revisar un diff grande de un tercero
Antes de integrar la actualización de una dependencia empaquetada, quien mantiene el proyecto genera un mensaje de commit que resume el alcance real del cambio a partir del diff crudo.
Preguntas frecuentes
¿Sigue el formato Conventional Commits?
Sí, devuelve un tipo, un alcance inferido cuando corresponde, y una descripción concisa siguiendo la convención Conventional Commits de la que dependen herramientas como semantic-release.
¿Qué debo enviar, una descripción o el diff real?
El diff real. Leer las adiciones y eliminaciones reales produce un mensaje más preciso que pedirle que resuma su propio cambio de memoria.
¿Puede generar un cuerpo de commit más largo, no solo la línea de resumen?
Se enfoca en un tipo, alcance y línea de resumen precisos; agregue usted mismo un cuerpo más largo para contexto de negocio, como una referencia a un ticket, que el diff en sí no puede revelar.
¿Hay un plan gratuito?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Cuánto cuesta cada solicitud?
$0.003 por solicitud más $0.0135 por diff, y solo se cobran las tareas que se completan con éxito.
¿Qué pasa si la solicitud falla?
Se reintenta automáticamente hasta tres veces; una falla persistente devuelve un error claro sin ningún cobro.
¿Puedo usarla para reescribir mensajes en una rama vieja antes de aplastar commits?
Sí, enviar el diff de cada commit por separado y regenerar su mensaje es una forma común de limpiar el historial antes de un rebase interactivo.
¿Se conserva el diff que envío después?
No. Los diffs enviados y los mensajes generados se eliminan al vencer el período de retención y nunca se usan para entrenamiento.
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, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/commit-message \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/dev/commit-message", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/commit-message",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/commit-message", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/commit-message", 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
{
"input": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.commit_message",
"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. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |