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.

Estrategias de branching 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.

1. 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.

2. 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.

3. 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).

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 empujar una rama a 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 checkout -b 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.

Rastrear 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 checkout nombre-rama-remota

Esto creará una copia local de la rama remota en tu repositorio.

Eliminar una rama remota

Si una rama ha sido fusionada o ya no es necesaria, puedes eliminarla del repositorio remoto.

Eliminar una rama remota:

1git push origin --delete nombre-rama

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

Identificar archivos en conflicto: Usa git status para ver los archivos en conflicto:
```
1git status
```
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.
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
```
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.

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

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

1git checkout -b nueva-funcionalidad

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

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

Empujar la rama al repositorio remoto:

1git push origin nueva-funcionalidad

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.
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.

Resumen

Trabajar en equipo con Git implica organizar el trabajo de manera eficiente mediante estrategias de ramas como GitFlow o GitHub Flow, gestionar las ramas remotas para mantener un código limpio y organizado, y resolver conflictos colaborativos de manera efectiva. Los pull requests son una herramienta esencial para garantizar la calidad del código y facilitar la revisión antes de la integración de cambios en la rama principal. Siguiendo estas estrategias y prácticas, los equipos pueden colaborar de manera eficiente y productiva.

Curso git nivel medio