Git: ramas y flujos de trabajo

El código de producción es estable. El código nuevo está a medias. Y dos desarrolladores trabajan en funcionalidades distintas al mismo tiempo. Sin un mecanismo para aislar ese trabajo, cualquier cambio puede romper lo que ya funciona. Las ramas de Git existen exactamente para resolver ese problema.

¿Qué es una rama?

Una rama es un puntero ligero a un commit concreto. Cuando creas una rama, Git no duplica el código: simplemente crea una etiqueta que apunta al commit actual y avanza de forma independiente a medida que haces nuevos commits.

Todas las ramas coexisten en el mismo repositorio. El trabajo en una rama no afecta a las demás hasta que decides fusionarlas.

Comandos esenciales

# Ver todas las ramas (local)
git branch
# Ver ramas locales y remotas
git branch -a

# Crear una rama nueva
git branch feature/login

# Cambiar a una rama existente
git switch feature/login        # recomendado (Git 2.23+)
git checkout feature/login      # forma antigua, equivalente

# Crear y cambiar en un solo paso
git switch -c feature/login

# Fusionar una rama en la rama actual
git switch main
git merge feature/login

# Eliminar una rama (ya fusionada)
git branch -d feature/login

# Forzar el borrado (no fusionada)
git branch -D feature/login

# Ver qué rama está activa
git status

Merging: cómo se fusionan las ramas

Cuando fusionas una rama, Git tiene dos estrategias principales:

• Fast-forward: si la rama de destino no ha avanzado desde que creaste la feature, Git simplemente mueve el puntero hacia delante. No crea un commit de merge. El historial queda lineal.
• Merge commit: si ambas ramas han avanzado en paralelo, Git crea un commit extra que une los dos historiales. El historial refleja que hubo trabajo paralelo.

# Forzar merge commit aunque sea posible fast-forward
git merge --no-ff feature/login

# Ver el historial con gráfico de ramas
git log --oneline --graph --all

Flujos de trabajo

Un flujo de trabajo (o workflow) es un conjunto de convenciones sobre qué ramas existen, cómo se nombran y cuándo se fusionan. No hay un estándar único: el flujo correcto depende del tipo de proyecto y del equipo.

Git Flow

Git Flow define cinco tipos de ramas con roles específicos:

• main: solo contiene código en producción. Cada commit en main corresponde a una versión estable. Nunca se trabaja directamente en esta rama.
• develop: rama de integración. Las features se fusionan aquí antes de llegar a main.
• feature/*: una rama por cada funcionalidad nueva. Se crea desde develop y se fusiona de vuelta en develop cuando está lista.
• release/*: cuando develop está lista para una nueva versión, se crea una rama release para los últimos ajustes y pruebas. Se fusiona en main y en develop.
• hotfix/*: parches urgentes sobre producción. Se crean desde main y se fusionan en main y develop.

# Crear una feature desde develop
git switch develop
git switch -c feature/carrito

# … commits …
# Fusionar de vuelta en develop
git switch develop
git merge --no-ff feature/carrito
git branch -d feature/carrito

# Preparar una release
git switch -c release/1.2 develop

# … últimos ajustes, bump de versión …

# Fusionar en main y etiquetar
git switch main
git merge --no-ff release/1.2
git tag -a v1.2 -m "Versión 1.2"

# Fusionar también en develop
git switch develop
git merge --no-ff release/1.2

Git Flow es potente pero tiene bastante ceremonia. Encaja bien en proyectos con releases numeradas y ciclos de publicación fijos: aplicaciones móviles, librerías, software con versiones instaladas por los usuarios.

GitHub Flow

GitHub Flow simplifica el modelo al máximo: solo existen dos tipos de ramas. main siempre está en estado deployable, y cualquier trabajo nuevo va en una rama de feature que se fusiona mediante Pull Request.

# El ciclo completo en GitHub Flow
git switch main
git pull origin main

# Crear la rama de feature
git switch -c feature/nueva-funcionalidad

# … commits …

# Subir la rama al remoto y abrir Pull Request
git push origin feature/nueva-funcionalidad
# → abrir PR en GitHub/GitLab → revisión → merge → deploy

GitHub Flow funciona especialmente bien en aplicaciones web y SaaS con deploy continuo: cada merge a main dispara un despliegue automático. La sencillez del modelo facilita que equipos pequeños mantengan un ritmo de entregas rápido.

Trunk-based development

En el extremo opuesto de Git Flow está el desarrollo basado en trunk: todos los desarrolladores hacen commits directamente en main varias veces al día, con ramas de feature muy cortas (horas, no días). Requiere una batería sólida de tests automáticos y feature flags para ocultar funcionalidades incompletas en producción. Es el modelo que usan equipos de alto rendimiento con madurez técnica suficiente para sostenerlo.

¿Cuál elegir?

• GitHub Flow para la mayoría de proyectos web con deploy continuo.
• Git Flow cuando el proyecto tiene versiones numeradas, múltiples releases activas en paralelo o equipos grandes con procesos de QA formales.
• Trunk-based si el equipo tiene tests robustos y quiere el ciclo de feedback más corto posible.

Tener claro qué rama existe y para qué sirve es la mitad del trabajo. La otra mitad es saber qué ocurre cuando dos ramas han evolucionado por separado y hay que unirlas: ahí es donde aparecen los conceptos de merge, rebase y resolución de conflictos.