DEV Community

Cover image for Guía rápida: Consejos para hacer buenos mensajes de commit en Git 😀
Cristian Fernando
Cristian Fernando

Posted on

Guía rápida: Consejos para hacer buenos mensajes de commit en Git 😀

Índice

  1. Introducción
  2. Usa verbos imperativos
  3. No uses puntos finales
  4. Usa como máximo 50 caracteres
  5. Agrega todo el contexto necesario en el cuerpo del commit
  6. Usa prefijos
  7. ¿Y los nombres de ramas?
  8. Referencias
  9. Conclusiones

1. Introducción

Mantener un estándar en la gestión de nuestros mensajes de commit en un repositorio git es super importante para mantener consistencia al momento de trabajar con otras personas.
Siempre es mejor tener un estándar base por mas básico que sea a no tener uno.
Por ello en este post explicaremos algunas reglas prácticas útiles para poder escribir mensajes de commit más eficientes y legibles.

2. Usa verbos imperativos

Los verbos en imperativo son aquellos que se utilizan para dar órdenes, consejos, instrucciones, sugerencias o pedidos a otra persona.
Puede parecer un poco agresivo usar estos verbos para tus commits pero también es una muy buena manera de escribir mensajes.

Por ejemplo puedes usar verbos como add, fix, remove, update, _merge _, etc.

Lo importante es que el commit complete la siguiente frase:
"Si aplico este commit, entonces este commit…"

  • ...add a new search feature • ...fix a problem with the topbar • ...change the default system color • ...remove a random notification

3. No uses puntos finales

Es una mala practica agregar puntos finales o puntos suspensivos al finalizar un mensaje

git commit -m "Add new search feature." # Mal. Con punto final.
git commit -m "Fix a problem with the topbar..." # Mal. Puntos suspensivos
git commit -m "Change the default system color" # Bien.
Enter fullscreen mode Exit fullscreen mode

¿Por qué es una mala práctica? El primer mensaje del commit es el título del mismo, por reglas gramaticales nunca se deben usar puntos en un título.

4. Usa como máximo 50 caracteres

No escribas commits muy largos. Si un commit tiene mucho texto posiblemente esté haciendo esa confirmación sea muy grande por lo que se recomienda fraccionar ese commit. 50 caracteres por commit es un buen número para mantener consistencia en el repositorio.

# MAL. Muy largo.
git commit -m "Add new search feature and change typography to improve performance"
# BIEN. Corto, comprensible.
git commit -m "Add new search feature"
# BIEN. Al grano pero con detalle.
git commit -m "Change typography to improve performance"
Enter fullscreen mode Exit fullscreen mode

5. Agrega todo el contexto necesario en el cuerpo del commit

Recuerda que cuando hacemos git commit -m "Titulo del commit" este -m solo sirve para darle un título a la confirmación, podemos usar un segundo -m para darle una descripción más detallada.

git commit -m "Add new feature" -m "Application login completed"
Enter fullscreen mode Exit fullscreen mode

Otra opción que tenemos sería agregar el mensaje de manera manual sin pasarle la bandera -m, esto nos abrirá Vim en la línea de comandos y podremos escribir un mensaje más largo y descriptivo de una manera más cómoda.

6. Usa prefijos

Cuando el proyecto crece se sugiere usar commits semánticos con la siguiente estructura:

[tipo-commit](scope): mensaje

Por ejemplo podemos usar los tipos de commit que usa el equipo de angular:

  • feat: para una nueva característica para el usuario.
  • fix: para un bug que afecta al usuario.
  • perf: para cambios que mejoran el rendimiento del sitio.
  • build: para cambios en el sistema de build, tareas de despliegue o instalación.
  • ci: para cambios en la integración continua.
  • docs: para cambios en la documentación.
  • refactor: para refactorización del código como cambios de nombre de variables o funciones.
  • style: para cambios de formato, tabulaciones, espacios o puntos y coma, etc; no afectan al usuario.
  • test: para tests o refactorización de uno ya existente.

Por ejemplo:

  • fix(frontend): remove wrong color
  • docs(backend): add enpoint users API
  • feat(movile): add logging users

7. ¿Y los nombres de ramas?

Así como los commits semánticos y con estructura mejoran la legibilidad de nuestro repositorio, también podemos hacerlo con el nombre de nuestras ramas.

Una buena manera seria indicar que hace una rama:

  • bug: Cambios de código para arreglar un bug conocido.
  • feature: Desarrollo de una nueva característica.
  • experiment: Experimentos que nunca serán fusionados.
  • hotfix: Cambio rápido de un error crítico.

Por ejemplo:

git branch experiment-feature-loggin
git branch hotfix-colors-css
Enter fullscreen mode Exit fullscreen mode

8. Referencias

La mayoría de la información de este post lo extraje del libro Aprendiendo Git de Midudev . Todos los créditos a él.

9. Conclusiones

Siempre es recomendable tener un estándar de commits y ramas con tu equipo, esto con la finalidad de mejorar el orden y la lectura de un repositorio.
Con estos consejos tendrás por demás para empezar a gestionar los commits de tu proyecto. Recuerda que no todas las reglas son obligatoriamente aplicables, cada equipo puede tener su estándar. ¡Lo importante es tener uno!


Otros post de mi autoría que te pueden interesar:

end

Top comments (0)