¿Cómo colaborar en equipo con Git y GitHub?

Colaborar en equipo con Git y GitHub significa que varias personas trabajan sobre el mismo repositorio usando ramas, forks y pull requests para integrar cambios de forma ordenada.

Este flujo evita que los desarrolladores sobrescriban el trabajo de otros. También permite revisar el código antes de que llegue a la rama principal.

El modelo de colaboración en equipos profesionales

Existen dos modelos principales de colaboración en GitHub.

Modelo de repositorio compartido: todos los integrantes tienen acceso directo al repositorio. Se usa en equipos internos de empresas como el equipo de tecnología de Liverpool o FEMSA.

Modelo fork + pull request: cada colaborador copia el repositorio a su cuenta, trabaja en su copia y propone cambios. Se usa en proyectos de código abierto y en equipos distribuidos.

Ambos modelos usan pull requests como mecanismo de revisión. La diferencia está en quién tiene permiso de escritura directo.

¿Qué es un fork?

Un fork es una copia completa de un repositorio que queda bajo tu cuenta de GitHub. No afecta al repositorio original hasta que tú propones un cambio.

Para hacer un fork, entra al repositorio en GitHub y haz clic en el botón Fork (arriba a la derecha). GitHub crea una copia idéntica en tu cuenta en segundos.

Después, clona tu fork a tu máquina:

git clone https://github.com/tu-usuario/nombre-del-repo.git
cd nombre-del-repo

Con esto tienes el código en tu computadora y puedes empezar a trabajar.

Cómo mantener tu fork actualizado

Cuando el repositorio original recibe nuevos commits, tu fork se queda atrás. Necesitas sincronizarlo manualmente.

Primero, registra el repositorio original como un remoto llamado upstream:

git remote add upstream https://github.com/empresa/nombre-del-repo.git

Después, descarga los cambios de upstream y actualiza tu rama principal:

git fetch upstream
git checkout main
git merge upstream/main

Finalmente, sube la actualización a tu fork en GitHub:

git push origin main

Haz esto antes de comenzar cualquier tarea nueva. Así evitas conflictos innecesarios.

El flujo de trabajo con ramas por tarea

Nunca trabajes directo en main. Crea una rama específica para cada tarea o corrección.

Estructura del nombre de rama:

tipo/descripcion-corta

Ejemplos reales que usa un equipo de desarrollo en Mercado Libre:

Esta convención ayuda a identificar el propósito de cada rama de un vistazo.

Para crear y moverte a tu nueva rama:

git checkout -b feature/filtro-precio-mlp

Trabaja en esa rama, haz tus commits y luego súbela a GitHub:

git push origin feature/filtro-precio-mlp

¿Qué es un pull request?

Un pull request (PR) es una solicitud formal para que el equipo revise e integre tu rama en main. No es un comando de Git. Es una función de GitHub.

Cuando subes una rama nueva, GitHub muestra un botón verde que dice "Compare & pull request". Haz clic ahí.

Un buen pull request incluye:

• Título claro: describe qué hace el cambio. Ejemplo: Agrega filtro de precio en listado de productos.
• Descripción: explica por qué es necesario el cambio y cómo probarlo.
• Capturas o evidencia si el cambio afecta la interfaz visual.

Revisión de código (code review)

Una vez abierto el PR, los compañeros de equipo pueden dejar comentarios línea por línea. Esto se llama revisión de código o code review.

La revisión cumple tres funciones:

1. Detectar errores antes de que lleguen a producción.
2. Compartir conocimiento entre integrantes del equipo.
3. Mantener el estándar de calidad del código.

El revisor puede aprobar el PR, pedir cambios o rechazarlo con comentarios. El autor responde a los comentarios, hace nuevos commits y los sube a la misma rama. El PR se actualiza automáticamente.

Cuando el revisor aprueba, alguien con permisos hace clic en Merge pull request. Los cambios se integran a main.

Convenciones para un historial limpio

Los equipos profesionales siguen convenciones para que el historial de commits sea fácil de leer.

Conventional Commits

Conventional Commits es el estándar más usado. El formato es:

tipo(alcance): descripción corta

Ejemplos:

feat(carrito): agrega validación de stock antes de comprar
fix(login): corrige error de sesión en Safari móvil
docs(readme): actualiza instrucciones de instalación
refactor(api): simplifica lógica de autenticación

Los tipos más comunes son:

Esta convención permite generar changelogs automáticos y entender el historial sin abrir cada commit.

Un commit, una idea

Cada commit debe representar un solo cambio lógico. No mezcles la corrección de un bug con una nueva función en el mismo commit. Si necesitas separar cambios, usa git add -p para agregar partes de un archivo de forma selectiva.

Ejemplo completo: flujo de un desarrollador en Bimbo Digital

Supón que formas parte del equipo de tecnología de Bimbo y debes agregar una sección de descuentos en la tienda en línea.

Paso 1: Actualiza tu fork.

git fetch upstream
git merge upstream/main
git push origin main

Paso 2: Crea tu rama.

git checkout -b feature/seccion-descuentos

Paso 3: Trabaja y haz commits con el formato correcto.

git add src/components/Descuentos.jsx
git commit -m "feat(tienda): agrega sección de descuentos en página principal"

git add src/styles/descuentos.css
git commit -m "style(tienda): aplica estilos de sección de descuentos"

Paso 4: Sube tu rama.

git push origin feature/seccion-descuentos

Paso 5: Abre el pull request en GitHub con título y descripción claros.

Paso 6: Responde los comentarios del revisor. Si piden cambios, haz nuevos commits en la misma rama y vuelve a hacer git push. El PR se actualiza solo.

Paso 7: El líder del equipo aprueba y hace merge. Tu trabajo ya está en main.

Errores comunes

Error 1: Trabajar directo en main. Si haces commits directo en main y alguien más también lo hace, los conflictos son difíciles de resolver. Siempre crea una rama para cada tarea.

Error 2: Abrir un PR con demasiados cambios. Un PR que modifica 50 archivos es casi imposible de revisar bien. Divide tu trabajo en PRs pequeños y enfocados. Un equipo de FEMSA Tech limita sus PRs a no más de 400 líneas cambiadas.

Error 3: No sincronizar el fork antes de crear la rama. Si creas tu rama desde un main desactualizado, tu PR tendrá conflictos con el repositorio original. Siempre ejecuta git fetch upstream y git merge upstream/main antes de crear una rama nueva.

Error 4: Mensajes de commit vagos. Commits como arreglos o cambios varios no dicen nada. El equipo no puede entender el historial. Usa el formato de Conventional Commits desde el primer día.

Error 5: Hacer merge sin revisión. Integrar código sin que alguien más lo revise es una práctica de riesgo. Configura en GitHub la regla de required reviewers para que ningún PR se pueda mergear sin al menos una aprobación.

Resumen del flujo colaborativo

Este flujo es el estándar en equipos de tecnología en México y en todo el mundo. Dominarlo te permite integrarte a cualquier equipo profesional desde el primer día.