Trabajo colaborativo

Cuando trabajas con Git en equipo, es fundamental saber cómo usar repositorios remotos, colaborar de manera eficiente y seguir buenas prácticas. Plataformas como GitHub, GitLab y Bitbucket ofrecen un entorno adecuado para gestionar repositorios remotos, contribuciones y revisiones de código. Aquí te explico cómo manejar estos aspectos clave del trabajo colaborativo en Git.

1. Repositorios remotos: GitHub, GitLab, Bitbucket #

Un repositorio remoto es una copia de tu repositorio almacenada en un servidor accesible a través de internet. Los repositorios remotos permiten que varios desarrolladores trabajen en el mismo proyecto de manera colaborativa, cada uno con su propia copia local.

GitHub #

• GitHub es la plataforma más popular para alojar repositorios de Git y trabajar en proyectos colaborativos.
• Ofrece herramientas para gestionar issues (problemas), pull requests (solicitudes de cambios), y acciones para automatizar procesos (CI/CD).

GitLab #

• GitLab ofrece un entorno similar a GitHub, pero además incluye funcionalidades nativas avanzadas para CI/CD (integración y entrega continua).
• Se puede autohospedar, lo que permite a las empresas tener su propio servidor GitLab.

Bitbucket #

• Bitbucket es una plataforma que se integra fuertemente con las herramientas de Atlassian (como Jira). También permite trabajar con Git y Mercurial.
• Ofrece un enfoque más empresarial, con integración directa con herramientas de gestión de proyectos.

Cada plataforma tiene sus propias características y flujos de trabajo, pero todos funcionan bajo los mismos principios básicos de Git. Puedes clonar, hacer pull, push y trabajar con ramas en cualquier plataforma.

2. git fetch vs git pull #

Tanto git fetch como git pull se usan para traer cambios desde un repositorio remoto, pero tienen algunas diferencias importantes.

git fetch #

El comando git fetch descarga los cambios desde el repositorio remoto, pero no los fusiona automáticamente con tu rama local. Te permite ver los cambios antes de aplicarlos.

• Uso:

  1git fetch origin

• Qué hace:

  • Descarga todos los commits, archivos y referencias (ramas, etiquetas) nuevos del repositorio remoto.
  • No modifica tu rama actual ni fusiona los cambios automáticamente. Te da la oportunidad de revisar lo que ha cambiado antes de integrarlo.

git pull #

El comando git pull descarga los cambios y los integra en la rama actual. Por defecto suele hacerlo mediante un merge; si el equipo trabaja con historial lineal, usa explícitamente --rebase o configura esa preferencia.

• Uso:

  1git pull origin main

  Para una rama de trabajo propia, una opción habitual es:

  1git pull --rebase origin main

• Qué hace:

  • Descarga los últimos cambios del repositorio remoto y los fusiona con tu rama actual.
  • Si hay conflictos, te pedirá que los resuelvas antes de completar la fusión.

3. git push: Enviar cambios al repositorio remoto #

El comando git push se utiliza para enviar los commits locales al repositorio remoto. Es la contraparte de git pull, ya que permite que tus cambios sean visibles para otros colaboradores en el proyecto.

• Uso:

  1git push origin nombre-de-la-rama

• Qué hace:

  • Sube los commits de tu rama local al repositorio remoto.
  • Si es la primera vez que subes una rama nueva y no tienes push.autoSetupRemote true, debes usar git push -u origin nombre-de-la-rama para establecer la rama de seguimiento.
  • Empuje forzado seguro: si has hecho un rebase local y necesitas actualizar tu rama remota privada, usa siempre git push --force-with-lease en lugar del peligroso git push --force (que sobrescribe cambios de otros sin avisar).

4. Claves SSH y HTTPS para autenticación #

Git ofrece dos formas principales de autenticarte cuando te conectas a un repositorio remoto: SSH y HTTPS.

Claves SSH #

SSH es el método más seguro y conveniente para autenticarse en servicios como GitHub o GitLab. Con SSH, generas un par de claves (pública y privada), y la clave pública se almacena en la plataforma. Cada vez que haces una operación con el repositorio remoto, Git usa la clave privada para autenticarse automáticamente.

• Ventajas:

  • Seguridad criptográfica robusta.
  • No necesitas ingresar contraseñas en cada interacción.

• Configurar SSH:

  • Genera una clave SSH moderna:

    1ssh-keygen -t ed25519 -C "tu_email@ejemplo.com"

  • Añade tu clave SSH a GitHub o GitLab (ve a las configuraciones de tu cuenta y añade el contenido de id_ed25519.pub).

HTTPS y Tokens de Acceso Personal #

El acceso por HTTPS utiliza un Personal Access Token (PAT) o un gestor de credenciales (Git Credential Manager); plataformas como GitHub y GitLab ya no aceptan contraseñas de cuenta para operaciones de Git por terminal.

• Ventajas:

  • Funciona a través de firewalls corporativos que bloquean el puerto 22 (SSH).

• Buenas prácticas:

  • Generar tokens con permisos mínimos necesarios (fine-grained tokens) y fecha de expiración.
  • Usar un gestor de credenciales del sistema operativo para no ingresar el token continuamente.

5. Gestionar contribuciones con forks y pull requests #

En proyectos de código abierto o en grandes equipos, las contribuciones se gestionan a menudo a través de forks y pull requests.

Fork #

Un fork es una copia de un repositorio que pertenece a tu cuenta. Cuando haces un fork de un proyecto, obtienes tu propia copia del repositorio donde puedes trabajar y hacer cambios sin afectar al proyecto original.

• Uso:
  • Haz un fork de un repositorio en GitHub o GitLab.
  • Clona tu fork en tu máquina local:

    1git clone https://github.com/tuusuario/repositorio-fork.git

Pull request #

Un pull request (PR) es una solicitud para que los cambios que has hecho en tu fork sean revisados e integrados en el repositorio original. Los PR permiten que otros revisen tu código y comenten antes de aprobar los cambios.

• Flujo de trabajo:
  1. Haces un fork del proyecto.
  2. Realizas los cambios en tu fork.
  3. Creas un pull request para que los administradores del proyecto revisen e integren tus cambios en el repositorio original.

6. Colaborar con otros desarrolladores: buenas prácticas y flujos de trabajo #

Al colaborar en proyectos con Git, es importante seguir buenas prácticas y utilizar un flujo de trabajo adecuado para facilitar la integración de los cambios y minimizar conflictos.

GitFlow #

GitFlow es un flujo de trabajo robusto que define cómo usar ramas en Git para gestionar el desarrollo de un proyecto.

• Ramas principales:

  • main: Contiene el código listo para producción. Esta rama siempre debe estar estable.
  • develop: Es la rama donde se realiza la integración continua de todas las nuevas funcionalidades. Es una rama de preproducción.

• Ramas de soporte:

  • Feature branches: Ramas temporales que se crean para desarrollar nuevas funcionalidades. Se crean a partir de develop y, una vez completadas, se fusionan de nuevo en develop.
  • Release branches: Ramas temporales creadas cuando una versión está lista para ser preparada para su lanzamiento. Una vez que los errores se solucionan, se fusiona en main y develop.
  • Hotfix branches: Se crean a partir de main para solucionar rápidamente errores en producción. Se fusionan tanto en main como en develop.

GitHub Flow #

GitHub Flow es una versión más simple y ágil de GitFlow, ideal para proyectos donde la integración continua y los lanzamientos rápidos son esenciales.

• Flujo de trabajo:

  1. Todo el trabajo se realiza en ramas independientes creadas a partir de main.
  2. Cuando una nueva funcionalidad está lista, se crea un pull request para revisarla e integrarla en main.
  3. Una vez aprobado, se fusiona en main y se lanza a producción.

• Ventajas:

  • Simplicidad.
  • Ideal para desarrollo ágil y despliegue continuo.

Buenas prácticas generales #

• Commits frecuentes y descriptivos: Hacer commits pequeños y con mensajes claros ayuda a mantener un historial legible y fácil de rastrear.
• Crear ramas para cada tarea: En lugar de trabajar directamente en main o develop, es mejor crear una rama específica para cada nueva funcionalidad o corrección de errores.
• Revisiones de código: Utiliza pull requests para revisar el código antes de fusionarlo con las ramas principales. Esto asegura la calidad del código y ayuda a encontrar posibles errores antes de la integración.