¿Cómo usar Git para colaborar en equipos de desarrollo?

Git es un sistema de control de versiones que permite a varios desarrolladores trabajar en el mismo proyecto sin pisarse el trabajo.

Imagina que trabajas en el equipo de e-commerce de Liverpool. Son cinco desarrolladores. Todos editan el mismo archivo de código al mismo tiempo. Sin Git, el último en guardar borra el trabajo de los demás. Con Git, cada cambio queda registrado, identificado y protegido. Así es como los equipos profesionales colaboran sin caos.

El problema que Git resuelve

Antes de Git, los equipos compartían código por correo o por carpetas en Dropbox. Alguien sobreescribía el trabajo de otro sin darse cuenta. Recuperar una versión anterior era casi imposible.

Git resuelve esto con un registro histórico de cada cambio. Puedes ver quién modificó qué, cuándo y por qué. Si algo se rompe, regresas al punto anterior en segundos.

En equipos DevOps, Git no es opcional. Es la base sobre la que se construyen los pipelines de CI que aprendiste en la lección anterior. Sin commits ordenados, el pipeline no sabe qué probar.

El Sistema de Ramas: La Estrategia Trunk-Based Lite

La estrategia más usada en equipos medianos de México se llama Trunk-Based Lite. No es la estrategia más compleja, pero es la más práctica para equipos de 3 a 10 personas.

Funciona con tres tipos de ramas:

• main: el código que está en producción. Nadie escribe directo aquí.
• develop: el código que está listo para pruebas. Aquí se integran los cambios antes de subir a main.
• feature/nombre: una rama temporal por cada tarea o funcionalidad nueva.

Cada desarrollador crea su propia rama de feature, trabaja ahí, y luego abre un Pull Request hacia develop. Cuando develop está estable y probado, se fusiona a main.

Esta separación evita que el código roto llegue a los usuarios.

Los Comandos Esenciales

No necesitas memorizar decenas de comandos. Con estos ocho, cubres el 90% del trabajo diario en un equipo real.

Clonar un repositorio:

git clone https://github.com/equipo-femsa/app-logistica.git

Descarga el proyecto completo a tu computadora.

Ver el estado actual:

git status

Te muestra qué archivos cambiaste y cuáles están listos para guardar.

Crear una rama nueva:

git checkout -b feature/carrito-de-compras

Crea la rama y te mueve a ella en un solo comando.

Guardar tus cambios (commit):

git add .
git commit -m "Agrega validación de stock en carrito"

El mensaje del commit debe describir qué hace el cambio, no cómo lo hiciste.

Subir tu rama al servidor:

git push origin feature/carrito-de-compras

Ahora tu equipo puede ver tu trabajo en GitHub o GitLab.

Traer los cambios más recientes:

git pull origin develop

Actualiza tu rama local con lo que otros subieron a develop.

Fusionar ramas:

git merge develop

Incorpora los cambios de develop a tu rama actual.

Ver el historial:

git log --oneline

Muestra cada commit en una sola línea. Muy útil para entender qué pasó.

Ejemplo Real: El Flujo de un Desarrollador en Bimbo

Supón que eres desarrollador en el equipo digital de Bimbo. Te asignan una tarea: agregar un filtro de productos por categoría en su tienda en línea.

Así sería tu flujo completo:

Paso 1: Actualizas tu copia local.

git pull origin develop

Paso 2: Creas tu rama de trabajo.

git checkout -b feature/filtro-por-categoria

Paso 3: Escribes el código del filtro. Haces varios commits mientras avanzas.

git add .
git commit -m "Crea componente de filtro por categoría"

git add .
git commit -m "Conecta filtro con API de productos"

Paso 4: Subes tu rama.

git push origin feature/filtro-por-categoria

Paso 5: Abres un Pull Request en GitHub hacia la rama develop. Tu compañero revisa el código, hace comentarios, y tú corriges lo que sea necesario.

Paso 6: El pipeline de CI corre automáticamente. Si pasa las pruebas, el Pull Request se aprueba y se fusiona.

Este flujo garantiza que nadie rompe el trabajo de los demás. Y el historial de commits queda como documentación del proyecto.

Cómo Escribir Buenos Mensajes de Commit

Un mensaje de commit mal escrito es como una nota sin contexto. Tres meses después, nadie sabe qué hiciste.

Usa este formato simple:

[tipo]: [descripción corta en presente]

Los tipos más comunes son:

• feat: una funcionalidad nueva
• fix: corrección de un error
• docs: cambios en documentación
• refactor: mejora de código sin cambiar funcionalidad

Ejemplos concretos:

En el contexto del SAT o del IMSS, donde los desarrolladores manejan datos fiscales sensibles, los mensajes claros son parte del estándar de calidad. Un auditor puede rastrear exactamente qué cambió y cuándo.

Errores Comunes al Colaborar con Git

Estos son los errores que más se repiten en equipos que apenas adoptan Git.

Error 1: Trabajar directo en main. Nunca hagas commits directo en main. Si subes código roto, afectas a todos. Crea siempre una rama de feature.

Error 2: Commits gigantes con decenas de archivos. Un commit debe representar un cambio lógico y pequeño. Si cambias 40 archivos en un solo commit, nadie puede revisar tu trabajo con claridad. Divide el trabajo en commits pequeños y descriptivos.

Error 3: No hacer pull antes de trabajar. Si no actualizas tu rama local, trabajarás sobre código viejo. Cuando intentes hacer push, Git te rechazará porque tu historial está desactualizado. Haz git pull siempre al inicio de tu jornada.

Error 4: Mensajes de commit sin sentido. Mensajes como "wip", "arreglo" o "asdfgh" son inútiles. Tu yo del futuro y tus compañeros los odiarán. Tómate 10 segundos para escribir un mensaje claro.

Error 5: Ignorar los conflictos de merge. Cuando dos personas editan la misma línea de código, Git genera un conflicto. Muchos desarrolladores entran en pánico. La solución es simple: abrir el archivo, leer las dos versiones, elegir la correcta y hacer commit. Git te marca exactamente dónde está el conflicto con <<<<<<, ====== y >>>>>>. No lo ignores.

Error 6: No usar .gitignore. Subir archivos de configuración con contraseñas, tokens o variables de entorno es un riesgo de seguridad grave. Usa siempre un archivo .gitignore para excluir .env, node_modules/, y cualquier archivo con datos sensibles. Esto es especialmente crítico si tu proyecto se conecta con APIs del SAT o del IMSS.

Cómo Conectar Git con el Pipeline de CI

Recuerda lo que aprendiste en la lección anterior: el pipeline de GitHub Actions se dispara con cada push y con cada Pull Request.

Eso significa que tu disciplina con Git afecta directamente la calidad del pipeline. Si haces commits pequeños y claros, el pipeline falla en un punto específico y sabes exactamente qué lo causó. Si subes un commit gigante con 50 cambios, el pipeline falla y no tienes idea de cuál de los 50 cambios rompió todo.

La regla de oro es: un commit, un propósito. Así el pipeline te da retroalimentación útil, no ruido.

Tu Flujo Diario en Tres Pasos

Para que esto sea un hábito, simplifícalo al máximo. Cada mañana antes de escribir código:

1. git pull origin develop — Actualiza tu rama con lo más reciente.
2. git checkout -b feature/nombre-de-tu-tarea — Crea tu rama de trabajo.
3. Trabaja, haz commits pequeños con mensajes claros, y abre un Pull Request al terminar.

Si sigues estos tres pasos todos los días, nunca tendrás conflictos graves ni código perdido.

El equipo que domina Git no trabaja más rápido porque escribe más código, sino porque pierde menos tiempo apagando incendios que ellos mismos causaron.