Diff → Conventional Commit
Pegue un git diff y automáticamente inferirá type/scope desde los archivos modificados para generar una plantilla de mensaje de commit. Admite formato Conventional Commits, valida la línea de asunto a 50 caracteres, detecta BREAKING CHANGE y genera un prompt listo para enviar a IA.
📋 Cómo capturar
# Todos los cambios git diff # Sólo lo que está en stage git diff --cached # Un commit concreto git show abc123 # Sólo nombres de archivo, si el diff es enorme git diff --stat
📖 Dónde se suele tropezar
Pega la salida de git diff y esto deduce un type y un scope a partir de los archivos cambiados y el recuento de líneas, y luego monta una plantilla de Conventional Commits y un prompt para entregar a una IA. Todo se ejecuta en el navegador. Lo que se puede deducir es qué cambió; por qué cambió no aparece en ningún sitio de un diff, y lo segundo es siempre lo que quiere saber quien lo lea después.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| El type deducido no encaja | El type se deduce de rutas y extensiones, así que no distingue dos intenciones distintas tras editar el mismo sitio. Tocar archivos de test sugiere test, pero si estabas actualizando expectativas junto a una corrección, fix puede ser la etiqueta honesta. La frontera entre docs y chore, o entre refactor y fix, es igual de invisible en un diff. |
Toma la deducción como punto de partida y sobrescríbela siempre tú. El criterio cuando dudes es si el comportamiento cambió desde el punto de vista del usuario. Si cambió, feat o fix; si no, refactor, chore, test o docs. Esa regla rinde directamente al generar notas de versión: sólo los cambios que merece mostrar caen en los dos primeros, y nadie tiene que separarlos a mano después. |
| Un commit con varios cambios dentro | Cuando el scope deducido sale como (*) o como una lista, es señal de que el commit es demasiado grande. Con una corrección, una refactorización y una subida de dependencia en el mismo commit, un git revert posterior se lleva también lo que querías conservar. Y embota el git bisect: cuanto mayor sea el commit al que llegue, menos habrá acotado. |
Usa git add -p para preparar por fragmentos y confirmar un significado cada vez; así puedes separar un árbol de trabajo que ya los mezcla. La prueba es si puedes describir el commit en una frase: si la frase necesita una "y", divídelo. Pega por separado cada diff resultante en esta página y obtendrás una plantilla para cada uno. |
| La IA sólo devuelve un resumen del diff | Si entregas sólo el diff, el modelo únicamente ve el cambio en el código. Lo que devuelve es una reformulación de lo que el diff ya muestra: añadido esto, corregido aquello. El valor de un mensaje de commit está en registrar lo que el diff no puede contarte, así que un mensaje así no se ha ganado su sitio. | Añade una o dos líneas con tus propias palabras sobre por qué hiciste el cambio antes de entregar el prompt generado. Un solo hecho externo —tres avisos de timeout al mes, un tipo impositivo que cambió por ley— transforma la calidad de la respuesta. Y añadir el número de incidencia relacionado permite a quien lo lea dentro de seis meses seguir todo el hilo. La biblioteca de prompts tiene plantillas de las que copiar. |
La ventaja práctica de Conventional Commits es que de los mensajes se puede generar el changelog y el número de versión: herramientas como semantic-release asignan fix a un parche, feat a una versión menor y cualquier cosa con BREAKING CHANGE a una mayor. Y a la inversa: un solo commit que no siga la convención vuelve poco fiable esa automatización. Si lo adoptas, mete commitlint en un hook de pre-commit y deja que una máquina imponga el formato: una convención sostenida sólo por buenas intenciones no es algo que nadie haya visto durar.
📖 Cómo usar
-
1
Copia diff`git diff`
-
2
Pega y sugiereAuto-detecta
-
3
Copia y commitCopia → commit
❓ Preguntas frecuentes
¿Detección type?
¿AI necesario?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.