¿core.extension.yml es un feat, un build o depende? ¿Un cambio en DDEV? ¿Una actualización de Composer? ¿Y los 40 YAML que genera un drush cex? ¿Qué hacemos con los archivos que empezamos a generar para trabajar con IA?
Después de más de cinco años utilizando Conventional Commits en proyectos Drupal, he acabado desarrollando mis propias reglas, trucos y, probablemente, alguna que otra manía.
En esta charla quiero compartir esa experiencia práctica: cómo aplicar Conventional Commits a un proyecto Drupal real sin convertir cada git commit en un debate filosófico.
Hablaremos de situaciones habituales como módulos custom, configuración exportada, Composer, DDEV, tests, CI/CD, refactorizaciones y correcciones de bugs. Pero también de problemas que empiezan a aparecer con el desarrollo asistido por IA: archivos de contexto, grafos generados con herramientas como Graphify, documentación para agentes y otros artefactos que plantean una nueva pregunta:
¿Esto forma parte del proyecto y debería estar en Git, o es simplemente un artefacto que podemos regenerar?
Y una vez decidido eso, aparece la siguiente pregunta:
¿Cómo lo contamos en nuestro historial de Git?
No será una charla para aprender de memoria qué significa feat, fix o chore. Veremos ejemplos reales, decisiones discutibles, errores habituales y criterios personales para decidir qué debe contener un commit, cuándo dividirlo y cuándo no complicarse la vida.
Porque Conventional Commits puede servir para mucho más que tener commits bonitos: puede hacer que dentro de dos años entendamos qué ocurrió en nuestro proyecto, que las herramientas automáticas puedan trabajar mejor con nuestro historial y que incluso nuestros asistentes de IA tengan un contexto más útil.
Y sí: también hablaremos de mis manías que dar charlas en la camp me sale más económico que hacer terápia.