A la hora de escribir código siempre es necesario prestar atención a los comentarios. Especialmente a que estos sean los necesarios, un exceso puede ser más una fuente de ruido que otra cosa, para que una persona pueda comprender lo que se presencia hacer. En especial, nosotros mismos en el futuro. Algo que también sucede en los sistemas de gestión de versiones. Los mensajes que se incluyen en cada subida deben hacer el mismo papel que los comentarios en el código: explicar qué cambios se incluyen y el motivo por el que incluyeron. Así, en futuras revisiones, cuando se busque un cambio en concreto será más fácil localizarlos. Para lo que se puede recurrir a la estandarización de los mensajes en Git. A continuación, propongo un método para crear estos de modo que sea fácil incluir la información necesaria.
¿Por qué estandarizar los mensajes de Git?
La estandarización de los procedimientos es algo que suele aportar grandes ventajas. Seguir un procedimiento a la hora de realizar una tarea evita el olvido de alguna parte, homogeneiza la calidad del producto final y al mismo tiempo que nos hace más productivos. Por eso, la estandarización de los mensajes en Git ofrece ventajas como:
- Hace que el historial de subidas sea más legible, facilitando de este modo la revisión del código.
- Facilita la redacción de los mensajes, ya no es necesario pensar qué escribir porque estará definido por el procedimiento.
- Evita olvidos, ya que todo lo que se necesita incluir estará en el estándar.
Información necesaria en un mensaje de Git
Antes de crear un estándar para los mensajes de Git es necesario pensar en qué información se debe incluir en estos. Lo que básicamente es:
- tipo: identificar si la subida es una nueva característica, la solución de un fallo, una refactorización de código, …
- detalle: señalar cuál es el cambio que se ha incluido, algo que se puede redactar con una frase.
- motivo: enlazar con el gestor de tickets para saber el mítico por el que ha introducido el cambio.
Propuesta básica para estandarizar los mensajes de Git
Con lo visto hasta ahora se puede pensar en una propuesta básica para estandarizar los mensajes de Git. Algo como lo siguiente:
tipo: detalle (motivo)
Así un mensaje podrá ser algo como:
característica: inclusión de la distribución Gumbel (164)
Con lo que se puede obtener de un vistazo la mayoría de la información necesaria. La subida es una característica, en concreto la inclusión de la distribución Gumbel, y el ticket asociado es el 164.
Incluir más información en el estándar
En algunos casos puede que el estándar propuesto anteriormente sea algo escaso. En grandes proyectos existen diferentes partes y puede que sea aconsejable saber cuales se ven afectadas. Además, puede que un mensaje corto no sea suficiente para explicar los cambios. En este caso es mejor dejar un título corto en la primera línea y escribir los detalles en una segunda (si, en Git es posible escribir mensajes de más de una línea). Una segunda línea que no debería exceder el tamaño de un tweet.
La parte del programa que se ve afectada se puede agregar al tipo de subida y escribir más líneas en el mensaje. Por lo que el estándar ampliado puede quedar algo como lo siguiente
tipo - alcance: detalle (motivo) descripción
En el caso del ejemplo anterior quedaría algo como lo siguiente:
característica - distribuciones: inclusión de la distribución Gumbel (164) En el módulo de distribuciones se incluye la distribución Gumbel
Conclusiones
En esta ocasión se ha propuesto un estándar para mejorar los mensajes de Git de cara a conseguir una estandarización de los mismos. Algo con lo que se puede servir para mejorar el trabajo de los equipos.
Imagen de Antonios Ntoumas en Pixabay
Deja una respuesta