Mejores prácticas en Git

Esta entrada es la tercera de la serie titulada "Introducción a Git y el control de versiones" escrita para ayudar en el uso efectivo de Git. En las publicaciones anteriores se explorarán conceptos básicos y avanzados de Git. En esta publicación, se profundizará en las mejores prácticas en Git. Lo que facilitará mantener un flujo de trabajo claro y eficiente, especialmente a la hora de colaborar en equipos de desarrollo.

La serie de publicaciones consta de las siguientes entradas:

1. Introducción a Git y el control de versiones
2. Comandos avanzados de Git y su aplicación
3. Mejores prácticas en Git
4. Introducción a la metodología GitFlow

Git, como principal gestor de versiones en la actualidad, es una herramienta clave dentro del desarrollo de software. Su principal aplicación es para gestionar los cambios de código en un proyecto y ayudar a que la colaboración entre desarrolladores sea eficiente. Sin embargo, debido a su flexibilidad, es fácil caer en prácticas que pueden generar caos y malentendidos dentro del equipo. En esta entrada se explicarán un conjunto de mejores prácticas en Git que pueden ayudar a maximizar la eficiencia y reducir fricciones al colaborar en proyectos de desarrollo. Al adoptar estas prácticas no solo se beneficia la productividad personal como desarrollador, sino que también ayuda a los equipos a trabajar de manera cohesionada y organizada.

¿Por qué son importantes utilizar las mejores prácticas en Git?

El uso adecuado de Git permite obtener los siguientes beneficios en los proyectos de desarrollo:

Algunos hábitos a la hora de trabajar con Git pueden hacer que estas ventajas se puedan perder en parte. Por lo que adoptar las mejores prácticas en Git permite obtener todas las ventajas de este gestor de versiones. Para ello se puede ver cómo mejorar el uso de Git desde la estructura de commits hasta la colaboración en equipo.

Commits: El corazón de Git

La parte fundamental de Git son los commits ya que es la confirmación de cambios en el repositorio.

Hacer commits pequeños y frecuentes

Una de las mejores prácticas clave en Git es realizar commits pequeños y frecuentes. En lugar de realizar un único commit grande con múltiples cambios no relacionados, trata de desglosarlos en commits específicos. Cada commit debe representar un único cambio lógico y coherente en el proyecto.

¿Por qué es importante?

Ejemplo práctico

En un formulario de inicio de sesión de un sitio web. Primero se hacen cambios en el HTML y luego en el CSS. En lugar de crear un solo commit que contenga ambos tipos de cambios, se puede separar cada uno en commits diferentes:

git add login.html
git commit -m "Añadir formulario de inicio de sesión en HTML"
git add login.css
git commit -m "Estilizar formulario de inicio de sesión con CSS"

Escribir mensajes de commit claros y descriptivos

Los mensajes de commit es como el resumen que identifica a cada uno de los cambios. Siendo la memoria del proyecto. Un buen mensaje debe describir claramente el cambio realizado, facilitando la comprensión del historial.

Estructura recomendada de un mensaje de commit

1. Línea de resumen (50 caracteres máximo): Breve y directa.
2. Descripción opcional: Explica el cambio en un párrafo adicional, si es necesario.

Adicionalmente se puede incluir información como el identificador del bug en el sistema de gestión de tickets (algunos pueden identificar y enlazar directamente con los commits). Siendo recomendable definir una estandarización de los mensajes en Git dentro del equipo

Ejemplo de buen mensaje de commit

git commit -m "Corrige el bug #234 en la función de validación de emails"

Para añadir más contexto se puede usar un editor de texto:

Corrige el bug #234 en la función de validación de emails

La validación fallaba cuando el email contenía caracteres especiales.
Se ha ajustado la expresión regular para manejar este caso.

Evitar los commits con trabajo en progreso

Es importante evitar la creación de commits con mensajes tipo trabajo en progreso (WIP, Work in Progress) ya que pueden dificultar la comprensión del historial. Lo ideal es que todo commit que se suba debe tener trabajo terminado y funcional.

Alternativas para manejar el trabajo en progreso

Si se necesita guardar un progreso temporal se puede usar una rama temporal en la copia local:

git checkout -b mi-caracteristica-wip
git commit -m "Progreso inicial en la característica"

Por otro lado, como se ha visto en la entrada anterior, se pueden guardar cambios sin realizar un commit empleando el comando git stash:

git stash

Uso de ramas: Mantener el desarrollo organizado

Al igual que las carpetas en un sistema de archivos, las ramas permiten organizar el desarrollo dentro de Git.

Crear ramas para cada característica o tarea

Para evitar conflictos y mantener el código organizado, una buena práctica es crear una rama separada para cada nueva característica o tarea.

Ejemplo

Si se está trabajando en una funcionalidad de autenticación, se puede crear una rama para esta tarea:

git checkout -b autenticacion-usuarios

Esto permite desarrollar la característica de manera aislada, sin alterar la estabilidad del código principal.

Nombres descriptivos para las ramas

Emplear nombres claros y descriptivos para las ramas es otra buena práctica en Git. Algunas convenciones incluyen iniciar para que se crea la rama:

Ejemplo de nombre para un bug en el inicio de sesión:

git checkout -b fix/bug-inicio-sesion

Uso eficiente de git merge y git rebase

Git ofrece varias formas de fusionar cambios: merge y rebase. Cada uno tiene sus pros y contras.

merge es común en equipos colaborativos, ya que crea un commit que combina el historial de dos ramas sin modificar su estructura original.

git checkout main
git merge autenticacion-usuarios

rebase reorganiza el historial, útil para evitar ramas divergentes y mantener una historia más lineal, pero debe usarse con precaución en ramas compartidas.

git checkout autenticacion-usuarios
git rebase main

Uso de Pull Requests (PR) o Merge Requests (MR)

Al colaborar, usar Pull Requests (PR) o Merge Requests (MR) para permitir la revisión de código antes de fusionarlo con la rama principal.

Ventajas del uso de PR/MR

Eliminar ramas innecesarias

Después de fusionar una rama, eliminar las ramas antiguas para mantener el repositorio ordenado:

git branch -d nombre-de-la-rama  # Local
git push origin --delete nombre-de-la-rama  # Remoto

Colaboración efectiva

De cara a mejorar la efectividad de la colaboración con Git es recomendable seguir algunas prácticas como las que se muestran a continuación.

Sincronizar el código frecuentemente

Al trabajar en equipo, sincronizar el trabajo de forma regular evita que puedan aparecer grandes conflictos que sean difíciles de resolver.

git pull origin main

Para una rama de larga duración, mantente actualizado con git fetch y git rebase:

git fetch origin
git rebase origin/main

Resolver conflictos de manera efectiva

Los conflictos de fusión ocurren cuando se colabora. Es algo natural. Por lo que es necesario revisar estos manualmente y añadir estos a la staging area para continuar:

git add archivo-afectado
git merge --continue

Mantener los conflictos mínimos sincronizados frecuentemente.

Mantenimiento del repositorio

Como cualquier proyecto vivo, es necesario mantener el repositorio limpio de cara a poder trabajar de forma más eficiente.

Mantén un historial de commits limpio

Para evitar confusión, es fundamental limpiar los commits usando git rebase -i para combinar commits menores antes de la fusión:

git rebase -i HEAD~3

Uso de tags para versiones

Usar tags para marcar versiones estables del proyecto. Los tags permiten volver a versiones previas con facilidad:

git tag -a v1.0 -m "Lanzamiento de la versión 1.0"
git push origin v1.0

Conclusiones

Seguir estas mejores prácticas en Git ayuda a maximizar la eficiencia, reduce la confusión y mejora la colaboración en los equipos. Desde hacer commits claros hasta gestionar ramas y resolver conflictos, cada práctica hace que el flujo de trabajo sea más organizado.

En la siguiente, y última entrada de la serie, se presentará la metodología GitFlow.

Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.