Recomendaciones para generar un buen commit
Tags: github, semanticcommits, git
Published: 2019-11-04 06:18:34

Durante el desarrollo de un proyecto es muy recomendable contar con una guía de buenas prácticas la cual nos facilite redactar ***commits*** que sean claros y puedan ayudar a cualquier miembro del equipo, esto para evitar que a medida que un proyecto se prolonga, los mensajes de los ***commits*** de mi ***git*** se vuelven cada vez menos informativos y podemos encontrar mensajes como ***ya funciona x parte** *los cuales en ocasiones no son ni descriptivos y peor aún en ocasiones ni el ***responsable*** recuerda o sabe lo que generó😒.

Por lo que para poder llevar de la mejor forma un proyecto es recomendable que todos los miembros del ***equipo*** adopten un estándar que les permite la redacción de ***commits***, con base a mi experiencia comparto las siguientes recomendaciones.

### 🚧 Estructura

El mensaje de un ***commit*** se divide en 3 partes diferentes el ***título**, **el cuerpo** y **pie*** como se muestra en el siguiente ejemplo.

![Ejemplo de estructura de un commit (**Fig-01**).](https://cdn-images-1.medium.com/max/2000/1*8zfZ8IPD88vt5oL5JVFahA.png)

Como se puede apreciar en la imagen anterior el título se conforma de dos partes las cuales son el *tipo y del asunto* del mensaje.

### 📓 Type/ Tipo

El tipo es contenido en el título y puede ser de alguno de los siguientes casos:
> # **➕ADD **: Se genera una nueva funcionalidad.
> # **🛠 FIX **: Se soluciona un bug.
> # **♻️ REFACTOR** : Refactorización y mejoras.
> # **☠️ DELETE** : Se eliminan funciones o archivos.
> # **📚 DOCS** : Se generar cambios en la documentación.

Es importante notar que el ***Type*** se escribe en mayúsculas y se puede utilizar emoji el cual es opcional en mi caso los utilizo ya que me facilita de primera vista saber el tipo de ***commit***.
> **🔖 Nota**: los tipos que se recomiendan en este caso pueden varias dependiendo del proyecto.

### ✉️ Subject/Asunto

El asunto no debe contener más de ***50 caracteres***, debe iniciar con una letra mayúscula y no terminar con un punto. Debemos ser *imperativos* al momento de *redactar* nuestro ***commit***, es decir, hay que ser ***objetivos*** y muy importante tenemos que acostumbrarnos a escribirlos en Inglés esto es una de las mejores prácticas que podemos tener.

### 📝 Body/Cuerpo

Se utiliza para explicar el ***¿Qué?*** y ***¿Por qué?*** del ***commit*** y no el ***¿Cómo?***, Al escribir el cuerpo, requerimos de una línea en blanco entre el título y el cuerpo, además debemos limitar la longitud de cada línea a no más de ***72 caracteres.***

### 👣 Footer/Pie

Esta parte es muy importante ya que es donde se coloca el seguimiento de los ***issues ***o*** tickets ***relacionados con los cambios generados.

### ❗️Ejemplo

Tomando en cuenta las recomendaciones mencionadas la estructura de nuestro **commit** se vería de la siguiente manera.

![Estructura final del commit (**Fig-02**).](https://cdn-images-1.medium.com/max/2000/1*r78c6kM2aYnaKz18yEUX5w.png)

> **🔖 Nota**: Para poder referencias un **issue** en el **commit** siempre se tiene que colocar **#** seguida del número de issue.

### 🤩Extra

Se recomienda generar ***commit*** por cambio este puede tener de uno a varios archivos lo recomendable es no tener demasiados archivos relacionados en un solo ***commit*** esto facilita la visibilidad al momento de realizar el ***Code Review ***ya que se puede realizar revisión por ***commit.***

### 😺 Conclusión

Contar con estándares y reglas dentro de nuestro equipo de trabajo al momento de redactar un ***commit** *es algo que nos puede evitar muchos dolores de cabeza al tratar de identificar o dar seguimiento a los cambios generados por el equipo, las recomendaciones mostradas anteriormente pueden ser modificadas ya que la intención es brindar una base para poder generar nuestras propias reglas.