Git & Version Control
Compón los campos o valida un mensaje completo. Cada modo conserva su propio borrador.
Los tipos propuestos son habituales. Puedes escribir un tipo propio.
Empieza con Refs: #42 o Closes #42. Las siguientes líneas normales continúan el valor anterior.
Los mensajes permanecen en este navegador, sin acceder al repositorio ni enviarlos por red.
Estructura Conventional Commits 1.0.0; sin reglas del proyecto ni límite de 50/72 caracteres. Máximo: 20.000 unidades UTF-16.
Introduce una descripción o un mensaje completo.
El Generador de mensajes de commit resulta útil cuando sabes qué cambió, pero quieres comprobar cómo queda expresado antes de crear el commit. Los Commits Convencionales separan el resumen, el contexto y las declaraciones de compatibilidad. Aquí puedes completar los campos y revisar un texto existente en borradores independientes, sin borrar uno para usar el otro. La vista final expone el mensaje y la intención de versión que declara.
El Generador de mensajes de commit une el tipo, el ámbito opcional y la descripción en la primera línea. Añade líneas vacías entre secciones y conserva los párrafos internos. Así puedes revisar un mensaje de commit completo, con sus pies, sin que la herramienta cambie un tipo personalizado o imponga otra combinación de mayúsculas y minúsculas.
Un feat suele declarar una evolución minor. Con ! antes de los dos puntos o un pie de ruptura válido, la declaración pasa a major, cualquiera que sea el tipo. El resumen muestra esta prioridad de forma explícita. No analiza el código ni decide si realmente se ha roto una interfaz o qué versión debe publicarse.
Las sugerencias son nombres habituales, no una lista cerrada. Puedes escribir un tipo propio de tu equipo. Elegir feat o fix exige conocer la modificación: el texto por sí solo no demuestra que una función sea nueva ni que un error haya quedado resuelto.
Empieza con Refs: #42 o Closes #42, por ejemplo. Una línea de texto normal continúa el valor anterior; otro par válido de token y separador abre una entrada nueva. Usa el campo de pies para declarar esa intención y revisa dónde termina el cuerpo.
El modo automático espera 350 ms desde el último cambio. Al desactivarlo aparecen el botón y Ctrl/Cmd + Enter. Modificar el texto, los campos o ! bloquea inmediatamente la copia y la descarga, hasta que se procese de nuevo esa entrada concreta.
La cabecera combina tipo, ámbito y descripción breve. Después puede haber varios párrafos y pies. Se conserva la escritura original, aunque FEAT y feat tienen la misma intención de versión. Puedes redactar las explicaciones en español; superar 50 o 72 caracteres no se considera por sí solo un error.
El validador comprueba la cabecera, la línea vacía necesaria y los pies reconocibles. Los errores conservan línea y columna de origen, y el editor destaca la línea correspondiente. Una URL o unos dos puntos dentro de una frase corriente no invalidan automáticamente el cuerpo. El borrador del formulario permanece disponible.
Coloca ! después del tipo o ámbito, justo antes de los dos puntos. Con ese signo no es obligatorio añadir un pie. También se admite BREAKING CHANGE: seguido de una explicación, o su equivalente BREAKING-CHANGE:. Estos tokens especiales deben escribirse en mayúsculas y los valores pueden continuar en otras líneas.
Se permite cualquiera de las dos formas. La especificación pide interpretar los tipos sin distinguir mayúsculas de minúsculas. Mantén un estilo coherente en tu equipo. El verificador conserva la escritura original, pero BREAKING CHANGE y BREAKING-CHANGE son excepciones: esos tokens deben estar en mayúsculas.
Cuando sea posible, divide los cambios con objetivos distintos en commits separados. Un mensaje tiene aquí un único tipo. El cuerpo puede explicar el contexto, pero escoger feat no demuestra que todos los cambios estén bien clasificados. Revisa por separado las posibles incompatibilidades.
fix declara patch, feat declara minor y ! o un pie de ruptura válido declara major. La ruptura tiene prioridad sobre el tipo. La página muestra esa intención sin conocer tu versión actual, las versiones preliminares ni las reglas de la herramienta que prepara tus publicaciones.
Si aún es un borrador, corrige el tipo y vuelve a comprobarlo. Un error como feet puede ser estructuralmente válido porque se permiten tipos propios. Modificar un commit existente es una operación aparte del repositorio; esta página no ejecuta amend ni rebase ni cambia el historial.
La especificación deja el comportamiento de revert a los autores de herramientas. Puedes usar el tipo revert y un pie Refs para señalar los commits afectados. El verificador acepta la estructura, pero no resta efectos de cambios anteriores ni determina la versión que corresponde publicar después.
¿Hay un formato que debamos revisar?
Vuelve al Generador de mensajes de commit, compara la declaración con el cambio real y exporta únicamente el resultado actual después de revisar su estructura.