Haz tus mensajes de GIT Commit PROFESIONALES con CONVENTIONAL COMMITS
HTML-код
- Опубликовано: 28 ноя 2022
- ¿Te gustaría mejorar tus mensajes de commit de una manera más semántica, profesional y que te sirva para automatizar ciertas tareas?
Eso lo puedes conseguir con los Conventional Commits, una especificación para dotar de mayor significado y legibilidad al historial de cambios de tu repositorio.
También te puede interesar:
GIT HOOKS: Mejora tu flujo de trabajo con HUSKY y LINT-STAGED
► • GIT HOOKS: Mejora tu f...
Únete a la MEJOR COMUNIDAD de programación y desarrollo web en español.
► / discord
Suscríbete y activa la campanita para no perderte ningún vídeo
► ruclips.net/user/carlosazaustre?su... 
Наука
Tienes el contenido en texto de este tutorial en mi blog
▶ carlosazaustre.es/conventional-commits
super, gracias por el porte
Muchas gracias me sirvió!!!!!
Esto si que es un contenido de calidad :)
😍😍 Muchas gracias Jefardo!
Ya lo utilizaba pero nunca lo habia configurado yo mismo gracias por el contenido
Minimo este tipo de videos deberia estar en tendencia 👌🏻🖤
Excelente tema! Lo empezare a utilizar en mi proximos proyectos. Gracias!
Hola Carlos, muchas gracias por el video, por suerte hace un tiempo que estoy trabajando con éste tipo de buenas prácticas, pero verlo todo en uno, me pareció muy bueno. Personalmente vengo trabajando hace algunos años con el enfoque de DoC (Documentation as Code) generando la documentación en forma rápida orientado a un release de código. El video me sirvió para solucionar algunas cosas que tenía sin resolver, como las validaciones antes de hacer el commit. Muchas gracias y por más videos así
Según tenía entendido, cuando se utiliza ‘style’ no es para indicar cambios en CSS sino para los cambios de estilo dentro del proyecto (por ejemplo; forzar automáticamente que todas las líneas tengan un ; al final)
Genial video!
Ahmmm puede ser… no había caído en eso. Gracias por el aporte!
Es correcto. La descripción de `style` es similar a esta "Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)"
Buenisimo video, facil explicacion y contenidp concreto. Saludos desde Colombia🇨🇴
No me sabía la mitad del video! Muchas gracias!
Me ha gustado. He creado mi propia forma de poner algo parecido en mis commits, pero me gusta que haya un estandar. Lo utilizaré.
Super bueno el contenido, a implementar en el equipo de desarrollo 👍
Gracias por el aporte
excelente aporte !! ahora a ponerlo en practica
Excelente video, felicitaciones. Con ansias de saber más del verdadero mundo dev, ojalá continúes con más videos así enfocados a proyectos pro!. Gracias
Muchísimas gracias Felipe!
¿Qué otros temas te gustaría ver?
Un vídeo súper práctico y útil Carlos, gracias mil por tu saber hacer y compartir. Sin duda me ayudará en el arranque de nuevos proyectos. Un saludete majo
Muchísimas gracias a ti Álvaro! me alegra que te haya servido el video :)
Justo el video que necesitaba, que bien contenido
Que bueno, me alegro John! Muchas gracias ☺️
Excelente video, seria genial un video usando monorepo a ver si hay alguna diferencia en la configuración, sobre todo con el changelog
Grande! gracias por compartir conocimiento
Un placer ☺
Gracias por el video, Carlos !
Me ha puesto a pensar en lo siguiente: cuando usamos conventional commits estamos asumiendo que cada commit va a generar una nueva versión de nuestro proyecto, siendo esta patch, minor o major. La verdad es que habemos muchos desarrolladores que hacemos commit cuando se nos da la gana y sin tener ese versionamiento en mente; seria muy bueno si añades las buenas practicas que hay que seguir en nuestro trabajo diario para no generar 12312 patches todos los dias. Un saludo !
Hola HoroHoro!
Muy buena pregunta y la respuesta la tienes en el fichero changelog. Al hacer un resumen de los commits que has hecho desde la ultima versión, tienes que mirar de todos, cual es el de "mayor" importancia. Imagina que desde la version publicada 1.0.0. hiciste 5 cambios/commits y el changelog te muestra:
- fix: bla bla bla
- fix: bla bla bla
- feat: bla bla bla
- fix: bla bla bla
- fix: bla bla bla
Aquí lo mas "grande" sería el feat, entonces tu nueva versión (si la vas a publicar, desplegar) sería 1.1.0
Espero que te haya servido :)
Me identifico con este comentario jajaja, lo importante es ir adoptando nuevos hábitos que nos ayuden a mejorar nuestros procesos como desarrolladores
oie si, en mi trabajo una vez tuve que llamarle la atencion a todos mis compañeros por que resulta que se subieron errores y quise depurarlo con la herramienta git bisect y cuando depuraba veia comentarios wtf como "se coloca var_dump, entra aqui en tal controller, espacios en blanco", jajajajaja me rei por dentro pero lo veia al jefe de TI molestaso jajajajajaja, bueno cabe recalcar que soy el que mejor maneja la herramienta de git en mi trabajo y no uso conventional commit por eso miraba el video, acostumbro a usar las nomeclaturas de git flows, como feature, bugfix, etc ....
Apoyo ese comentario ya que michas veces se nos olvida commitear solo una cosa y pasamos al siguiente problema ….. y luego a veces me n vez de commitear mucho commiteo poco pero con muchas cosas ya echas pfff es un toston… no es dificil programar a mi simple vista mas que la organizacion y comunicacion empleado empresa por ejemplo. Pfff😓😮💨
Vuelve la gorra y vuelve con un contenido pro!
Jajaja, la gorra da poderes de ultra instinto jajaja
Thanks for share this kind of content in Spnish....that is very usefull
Thank you man!
excelente!
Muy buen contenido, la verdad estaba pensando en buscar algo como esto, ya que en donde trabajo es solo hacer un git commit -m"etc" jejeje, buen aporte gracias!.
jeje, muchas gracias Geronimo. Si, la verdad es que nombrar variables y commits no es lo que mejor se nos da como programadores :P
Justo estaba pensando que mis commits no tenían buena estructura, este video como caído del cielo, thanks
Que bueno Jesus! Un placer 😊
Buenisimo
Gracias por el contenido esta excelente, siempre intento estandarizar mis commits pero a la final todo lo resuelvo con FIX o UPDATE jajajajajaja, a mejorar las prácticas. saludos
Jejej, yo también hago igual. Siguiendo esta norma me fuerzo a hacerlo mejor :)
Buen video! Yo lo utilizo en mi empresa pero siempre empezamos los commits en mayus tipo Feat... Fix... Siempre es bueno tener reglas de equipo para que no sea todo un caos
Por supuesto, lo importante es el consenso :)
Buen aporte, sobre todo después del de los husky hooks. Yo los uso para el linting y esto. Me gustaría concatenar también otro hook para el versionado semántico como el que has comentado, pero desde que trabajo con un monorepo no he investigado como meter un CHANGELOG.md por cada proyecto (app/librería). Lo que el monorepo te facilita con un solo "package" y node_modules compartidos, te lo complica con otras cosas como esta 😅.
Me sumo al comentario que indica que el tipo "style" es para cambios del formato del código y no del estilo de diseño (css, etc.).
Y sobre los comentarios de que cada commit generan una nueva versión (Major, minor o patch) yo he encontrado un par de soluciones:
1. Acumular commits en una rama y en el PR (Pull request), agruparlos en un squash commit para generar la versión semántica ahí (por ejemplo, agrupar un montón de commits en un `feat: add Dashboard page`.
2. La otra opción es no ejecutar el versionado semántico hasta terminar la funcionalidad, ya que a pesar de acumular múltiples feat commit, al ejecutar el sem-ver sólo te aumenta una minor (a no ser que alguno de ellos contenga Breaking Changes!).
Me gusta la idea de 1 commit por versión porque primero el árbol de commits queda mucho más limpio y segundo, te hace pensar en si lo que estás haciendo forma parte de la misma unidad funcional de tu proyecto, porque a veces podemos estar haciendo una feature y dentro de los commits meter algun de fix, eso ya te hace pensar que: o no debes mezclar esos dos cambios o tal vez estás considerando como fix al proceso normal de realizar cambios en tu nueva feature. No sé, genera buenas discusiones :)
Buena pregunta lo los CHANGELOGs en monorepo... no me lo había planteado. Quizá si separamos bien los scopes se pueda hacer algo.
@@CarlosAzaustre Ya he visto que en los nx monorepos viene instalado por defecto @jscutlery/semver para versionado de proyectos independientemente o en conjunto. También he encontrado multi-semantic-release.
@@MickyAleman Tienes razón, a mi me cuesta un montón no arreglar algún fix que cazo mientras desarrollo una feat o alguna otra cosa que no tiene relación 😅
Buen video… suscrito y like
Grande! ☺️
Cool!!! 😄
:)
Nice.
Hay alguna forma de que sube automáticamente de versión en el package.json?
y para la suite de jetbrains que extencion tienen?
Excelente video, por trabajo e investigación propia había visto solo un pedazo de todo, pero no tan claro como esto, gracias
Me queda una duda, ejemplo si tengo ya mi proyecto iniciado con un log de commits super largo, e implemento esto, había algún conflicto o solo es desde la implementación hacia delante?
No importa, no rompe con nada anterior. Pero si empiezas a usarlo ahora tu historial será más legible, asique no resta, solo suma :)
Se puede usar sin esas app externas como Husky?
Cómo se llama la extensión? Creo que nunca lo mencionas. Saludis
:O!!! ¿¿como pones ese icono en la consola de las ramas??
Pregunta, en el caso en que sea una feature grande y quiera hacer varios commits para ir guardando el progreso, como quedaría esto? Se reflejará cada uno de los commits así sea de una única feature o tendría que hacer un squash para solo quedarme con un único commit?
Puedes hacer un Squash & merge si estás usando Pull Requests, y si no, no importa. Puedes hacer tantos commits como quieras, cuando vayas a cambiar de versión, haces un CHANGELOG y el commit de mayor importancia:
Breaking Change > Feat > Fix
Es el que definirá si la siguiente versión a desplegar o publicar, es Major, Minor o Patch
Gracias por compartir... tienes canal de discord???
Claro! discord.gg/carlosazaustre
Excelente. Puedes compartir el link de la extensión de GitEmoji para vscode ?
Hola Seba! Viene incluido en la extensión de Conventional Commits:
marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits
Buen vídeo!. Aparte: ¿qué fuente es la del código fuente?
Gracias Arturo! Suelo utilizar Lilex
Se puede configurar para proyectos que no sean JS?
mmm supongo que si, pero linkarlo con Husky únicamente en JavaScript. Seguramente para otros lenguajes existan alternativas similares pero la desconozco.
esta muy interesante, tengo una pregunta, como funciona en la linea de comando sin utilizar el plugin es decir como puedo utilizar lo usado mi comando de git commit -m " " y linkiar lo a mi tarjeta issue de github? podrías darme alguna ejemplo?
Hola Fernando! Pues hay varias formas:
- Puedes ejecutar el comando 'git commit' sin nada mas y te saldra un editor de texto por consola para que escribas lo que quieras con la extensión que quieras.
- Otro truco es poner el mensaje de commit pero no cerrar las comillas, de esta forma al hacer intro te pedirá que sigas introduciendo texto:
ej:
$ git commit -m "Make everything work.
dquote>
dquote> Add magic code that fixes everything"
@@CarlosAzaustre muchas gracias, lo voy intentar
Hola. que pasa si para un commit tengo cambios tipo fix y de documentacion?
Lo ideal es que cada commit simplemente resuelva una cosa. Aunque no siempre podemos. Ahi decide tu, yo pondria fix
@@CarlosAzaustre gracias master!!
Cuál es la extensión de vscode?
Conventional Commits 👍
Para los que les pase como a mi que algunos comandos no les funcionaron porque han cambiado por el tiempo aqui va la solución:
El primero npm set-script prepare "husky install" no me funciona porque set-script lo quitaron en versiones recientes de npm, ademas husky cambió su comando a "husky" la solución es:
npm pkg set scripts.prepare="husky"
El segundo comando npx husky add .husky/commit-msg "npx --no -- commitlint --edit ${1}" no me funcionó porque "husky add" lo han quitado y la solución es:
echo "npx --no -- commitlint --edit ${1}" > .husky/commit-msg
luego si te sale un error relacionado a un script "test" faltante solo hace falta agregar el script "test" vacio al package.json, esto es porque husky por default quiere ejecutar los tests del repo como validación.