DEV Community

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

Posted on • Edited on

7 1

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

Heroku

Build apps, not infrastructure.

Dealing with servers, hardware, and infrastructure can take up your valuable time. Discover the benefits of Heroku, the PaaS of choice for developers since 2007.

Visit Site

Top comments (2)

Collapse
 
juan_duque profile image
Juan Duque 🐉

Buen post, me ayuda bastante ahora que estoy tratando de llevar buenas praticas con git.

Collapse
 
duxtech profile image
Cristian Fernando

muchas gracias a ti por leer mi post y dejar tu comentario

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay