Git en equipo

El trabajo en equipo con Git requiere buenas prácticas y flujos de trabajo eficientes para evitar problemas, como conflictos en los archivos o ramas desorganizadas. A continuación, desarrollaremos las estrategias clave que los equipos deben seguir para gestionar el código colaborativamente.

1. Estrategias de ramas en equipos #

El uso de ramas (branches) es fundamental para permitir que varios desarrolladores trabajen en paralelo sin interferir en el trabajo de los demás. Existen varias estrategias de branching que los equipos pueden usar para organizar su trabajo de manera eficiente.

GitFlow #

GitFlow es una estrategia popular que organiza el desarrollo mediante ramas específicas para diferentes etapas del proyecto. Se basa en dos ramas principales y varias ramas de soporte.

• Ramas principales:

  • main (o master): Contiene el código de producción. Siempre debe estar estable y lista para el lanzamiento.
  • develop: Es la rama donde se integran todas las nuevas funcionalidades antes de fusionarlas en main.

• Ramas de soporte:

  • Feature branches (ramas de características): Se crean a partir de develop para desarrollar nuevas funcionalidades. Cuando la funcionalidad está lista, se fusionan de nuevo en develop.
  • Release branches (ramas de lanzamiento): Se crean a partir de develop cuando el proyecto está listo para un lanzamiento. Se utilizan para solucionar errores antes de la liberación.
  • Hotfix branches (ramas de corrección urgente): Se crean a partir de main para corregir errores críticos en producción y luego se fusionan tanto en main como en develop.

Ventajas de GitFlow:

• Permite una gestión estructurada y controlada de versiones.
• Ideal para equipos que siguen un ciclo de lanzamiento tradicional.

GitHub Flow #

GitHub Flow es un enfoque más simple y ágil, ideal para proyectos que requieren integración continua y despliegues frecuentes. En este modelo, solo se utiliza una rama principal (main) y ramas de características temporales.

• Ramas principales:

  • main: Contiene el código listo para producción. Cada cambio que se fusiona en main está listo para ser desplegado.

• Ramas de soporte:

  • Feature branches: Se crean a partir de main para desarrollar nuevas funcionalidades. Una vez que la funcionalidad está completa y revisada, se fusiona de nuevo en main mediante un pull request.

Ventajas de GitHub Flow:

• Simplicidad.
• Ideal para proyectos con despliegues rápidos y continuos.

Trunk-Based Development #

En el Trunk-Based Development, todos los desarrolladores trabajan directamente en la rama principal (trunk o main), creando ramas pequeñas y de corta vida para cada cambio. Las ramas deben fusionarse en main lo antes posible para mantener la integración continua.

• Ventajas:
  • Promueve la integración frecuente y evita divergencias largas.
  • Ideal para proyectos con despliegue continuo (CI/CD).

2. Gestión de ramas remotas #

Cuando trabajas en equipo, es crucial entender cómo gestionar las ramas remotas. Las ramas remotas son versiones de tus ramas locales que están almacenadas en un servidor remoto (como GitHub, GitLab o Bitbucket).

Ver ramas remotas #

Puedes ver las ramas remotas usando el comando:

1git branch -r

Esto mostrará una lista de todas las ramas remotas que existen en el servidor.

Crear y publicar una rama en un repositorio remoto #

Cuando creas una nueva rama localmente y deseas compartirla con tu equipo, debes empujarla al servidor remoto.

• Crear una nueva rama:

  1git switch -c nueva-funcionalidad

• Empujar la rama al repositorio remoto:

  1git push -u origin nueva-funcionalidad

El argumento -u establece un seguimiento entre la rama local y la rama remota, de modo que futuros git push y git pull en esa rama sean más simples (o puedes habilitar git config --global push.autoSetupRemote true).

Seguir una rama remota #

Si otro miembro del equipo ha creado una nueva rama en el repositorio remoto y deseas trabajar en ella, primero debes traerla a tu repositorio local.

• Traer cambios remotos:

  1git fetch

• Cambiar a la nueva rama:

  1git switch nombre-rama-remota

Esto creará una copia local de la rama remota en tu repositorio y configurará automáticamente el seguimiento.

Eliminar ramas y limpiar referencias desactualizadas (--prune) #

Si una rama ha sido fusionada o ya no es necesaria:

• Eliminar una rama en el servidor remoto:

  1git push origin --delete nombre-rama

• Limpiar en tu máquina local las referencias a ramas remotas ya borradas: Cuando tus compañeros borran ramas en GitHub/GitLab, tu Git local sigue mostrándolas en git branch -r hasta que limpias el listado con:

  1git fetch --prune

  (También puedes configurarlo para que se ejecute siempre con git config --global fetch.prune true).

3. Resolución de conflictos en entornos colaborativos #

Cuando varios desarrolladores trabajan en un mismo proyecto, es común que haya conflictos al intentar fusionar cambios en un archivo que ha sido modificado por más de una persona. Los conflictos de fusión deben resolverse manualmente antes de que se complete la fusión.

Detectar conflictos #

Los conflictos generalmente ocurren durante una operación de fusión (git merge) o al hacer git pull. Si Git detecta un conflicto, te mostrará un mensaje como:

1Auto-merging archivo.txt
2CONFLICT (content): Merge conflict in archivo.txt

Resolver conflictos #

1. Identificar archivos en conflicto: Usa git status para ver los archivos en conflicto:

   1git status

2. Abrir el archivo en conflicto: Los archivos en conflicto contendrán secciones marcadas como:

   <<<<<<< HEAD
   Esto es el contenido de la rama actual.
   =======
   Esto es el contenido de la rama que estás fusionando.
   >>>>>>> nombre-rama-remota

   Aquí deberás decidir qué cambios mantener y qué eliminar, o combinar ambos manualmente.

3. Marcar el conflicto como resuelto: Una vez que hayas resuelto los conflictos en el archivo, añádelo al área de stage:

   1git add archivo.txt

4. Completar la fusión: Después de resolver todos los conflictos, completa la fusión haciendo un commit:

   1git commit

Evitar conflictos #

• Integración continua: Hacer commits y fusiones frecuentes reduce la posibilidad de grandes conflictos.
• Revisar los cambios antes de hacer pull: Usa git fetch para obtener los cambios y revisarlos antes de intentar fusionar con git merge.

4. Revisiones de código con pull requests #

Los pull requests (PR) son una forma estándar de revisar el código en plataformas como GitHub y GitLab. Permiten a los desarrolladores proponer cambios a un repositorio y solicitar revisiones antes de fusionar esos cambios en la rama principal.

Flujo de trabajo típico con pull requests #

1. Crear una rama: Cada nueva funcionalidad o corrección debe realizarse en una rama separada.

   1git switch -c nueva-funcionalidad

2. Hacer commits en la nueva rama: Realiza los cambios y confirmalos en tu rama.

   1git add .
   2git commit -m "Implementar nueva funcionalidad"

3. Empujar la rama al repositorio remoto:

   1git push origin nueva-funcionalidad

4. Abrir un pull request: En GitHub o GitLab, abre un pull request desde la interfaz web para que los demás puedan revisar tu código.

5. Revisión y aprobación: El equipo revisa el código, deja comentarios, y una vez aprobado, el pull request puede ser fusionado en la rama principal.

Beneficios de los pull requests #

• Revisiones colaborativas: Permiten que otros desarrolladores revisen el código antes de fusionarlo, lo que ayuda a detectar errores o mejorar la calidad del código.
• Historial claro: Los pull requests permiten un historial claro y rastreable de los cambios introducidos en el proyecto.

Buenas prácticas para pull requests #

• Hacer PRs pequeños y enfocados: Es más fácil revisar y aprobar cambios pequeños y específicos que grandes PRs con muchas modificaciones.
• Añadir descripciones claras: Explica el propósito del PR, los cambios introducidos, y cualquier contexto importante.
• Responder a los comentarios: Si alguien deja una sugerencia o encuentra un problema, responde y haz las correcciones necesarias antes de que se apruebe el PR.