Buenas prácticas en Git

En el mundo del software es inevitable tener que trabajar en equipos muy grandes y multidisciplinarios, lo cual, si no se gestiona de manera adecuada, puede llevar a un desastre. Es por este motivo que existe Git.

Git es un sistema de control de versiones distribuido pensado para gestionar el código fuente de cualquier proyecto. Este nos permite tener un registro exacto de qué cambios aplicamos en nuestro código fuente y quiénes son los que están colaborando. Al principio, trabajar con repositorios Git puede ser frustrante o difícil de organizar.

A lo largo de mi experiencia, he aprendido una serie de buenas prácticas que me facilitaron la colaboración y el mantenimiento del código a largo plazo. En esta guía, te compartiré algunos de estos principios para que puedas mejorar la gestión de tus propios proyectos.

Empecemos por lo básico y repasemos algunos conceptos clave:

Conceptos esenciales

• Git: es un sistema de control de versiones distribuido.
• Repositorio (Repo): es como una “carpeta” donde se guarda todo tu código fuente. Actúa en forma de historial de cambios de un proyecto.
• Commit: es un registro de los cambios realizados en el código en un momento específico. Piénsalo como un “checkpoint” o “punto de guardado”, ya que representa una “foto” del estado del proyecto.
• Branch (Rama): son como una subdivisión de la carpeta principal (repositorio). Estas contienen todos tus cambios que realizas sin afectar la versión principal del proyecto. Las ramas más importantes suelen llamarse “master” o “main”.
• Push: es un comando que envía tus cambios al repositorio en línea, permitiendo que tu versión esté sincronizada.
• Pull: es un comando que trae los cambios realizados por otros desde el repositorio en línea a tu repositorio local, permitiendo que tu versión esté sincronizada.
• Merge: la acción de “mergear” combina los cambios de una rama en otra. Esto es común cuando finalizas de trabajar en una rama y quieres aplicar tus cambios a la versión principal.
• Conflicto de Merge: a veces, cuando dos personas editan la misma parte del código en diferentes ramas, Git no puede combinar automáticamente los cambios, generando un conflicto, lo cual impide completar el merge.
• Pull Request / Merge Request (PR/MR): es una solicitud para que los cambios realizados en una rama se revisen antes de ser combinados en otra.

Buenas prácticas en el uso de Git

Uno de los aspectos más importantes a tener en cuenta, por sobre todo, es la consistencia. De nada sirve aplicar buenas prácticas si unos las siguen y otros no, por eso es importante que cuando definas un equipo de desarrollo o integres a alguien nuevo a un proyecto, dejes en claro cuáles son las prácticas que seguirán. Una vez te pones de acuerdo con tu equipo de que seguirán las mismas reglas de organización, puedes proseguir a definir las prácticas de Git. A continuación, te cuento cuáles han sido las reglas que he seguido para tener una buena organización de los proyectos en Git.

Nombramiento de Ramas (Branches)

Empezando por lo básico, lo primero que tienes que mantener en buen orden son las Ramas o Branches. Las mismas deben ser descriptivas y dar claridad del cambio y el alcance que cubren.

Un esquema para los nombres de ramas que me gusta seguir es el siguiente:

[tipo]/[descripción-corta]

Esto nos ofrece un claro y rápido entendimiento del propósito de dicha rama, además de que nos permite agrupar por tipo/categoría los cambios aplicados.

Los tipos de rama más comunes con los que me he encontrado son los siguientes:

• feature/: para nuevas funcionalidades.
• bugfix/: para corrección de errores.
• hotfix/: para arreglos urgentes en producción o ambientes importantes.
• refactor/: para mejoras de código sin cambiar la funcionalidad.
• docs/: para actualizaciones de documentación.

Aquí te dejo algunos ejemplos de ramas que siguen este nombramiento:

feature/grid-system
bugfix/button-alignment
hotfix/navigation-bug
refactor/mixins-optimization
docs/update-contributing-guide

También puedes optar por la versión simplificada de los tipos de ramas, como se muestra a continuación:

feat/grid-system

bug/button-alignment

hot/navigation-bug

ref/mixins-optimization

doc/update-contributing-guide

Mensajes y comentarios de commits

Lo siguiente en lo que hay que llevar un buen control es en los commits. Muchas veces hacemos pequeños cambios y, por prisa o pereza, escribimos los commits con un punto o un texto aleatorio. Esto está muy mal porque nos hace perder el registro de qué hace cada cambio. Por este motivo, es muy importante mantener un historial de commits claro y consistente. Puedes utilizar el siguiente formato, el cual considero muy simple y me ha dado muy buenos resultados:

**[tipo]: [descripción]**

Algunos de los tipos de commits más comunes que he utilizado son:

• feat: para nuevas funcionalidades.
• fix: para corrección de errores.
• refactor: para refactorización de código sin cambiar la funcionalidad.
• style: para cambios en estilos (formato, ortografía, etc.).
• docs: para actualizar la documentación.
• test: para añadir o modificar pruebas.
• chore: para tareas de mantenimiento (actualización de dependencias, configuraciones).

Ejemplos de commits:

feat: added new grid system for responsive layout
fix: corrected button alignment issue on mobile
refactor: optimized SCSS mixins for better performance
docs: updated README with installation instructions

Claridad en los PR/MR

Otro de los puntos más importantes a la hora de colaborar con muchas personas es la claridad de las solicitudes para unificar cambios, ya que los PR/MR suelen ser revisados y analizados por otros miembros del equipo es importante dejar mensajes claros y que no den lugar a malas interpretaciones del contenido de dichos PRs/MRs.

Titulos claros: Hay que dejar un titulo claro y entendible que permita a simple vista entender que contiene dicho MR.

Cuerpo del PR/MR

El cuerpo del PR puede ser extenso y contener diversos recursos cómo imágenes, videos, links u otros elementos que ayuden a quien hace la revisión del MR a entender el “porqué” de los cambios. Una plantilla muy útil que me gusta usar en los MRs es la siguiente:

### **Descripción:**

Descripción detallada de los cambios que incluye el PR,
esto incluye aclaraciones u otra información.

---

#### **Cambios clave:**

1. Esto es una lista que enumera los cambios más importantes.
2. Puede ser una lista multi-nivel:
   - De esta manera puedes agrupar mejor los cambios.
   - Y dar una explicación más clara.
   - Y detallada de lo que debe incluir este MR.

Conclusión:

Utilizar git no tiene porque ser una tarea frustrante o tediosa, si llevamos buenas prácticas y una comunicación clara con nuestro equipo podemos tener una organización muy eficaz y eficiente, lo cual a la larga se traduce en un código más organizado y funcional.

Espero que te haya gustado y hayas aprendido algo al leyendo sobre buenas prácitcas en git.

¡Hasta la próxima!