Ramas y estrategias de ramificación

Una rama es una línea de desarrollo independiente. Permite trabajar en una funcionalidad nueva o en una corrección sin tocar el código estable que usan los demás.

Piensa en una rama como un borrador aparte. Puedes hacer todos los ensayos que quieras; mientras no hayas fusionado, el trabajo de los demás no se ve afectado.

Sin ramas, todo el equipo escribiría en el mismo archivo al mismo tiempo: caos garantizado. Con las ramas, cada uno avanza en su carril y luego se reúne el trabajo con limpieza.

Los comandos de base ya vistos en el módulo 01:

# Crear una rama y cambiar a ella
git switch -c feature/login

# Listar las ramas
git branch

# Volver a main
git switch main

🔧 Mini-ejercicio — Escribe el comando moderno para crear una rama feature/login y cambiar a ella de una sola vez.

En un equipo, no se crean ramas al azar: se les da un rol y un nombre convencional. Estos son los tipos más extendidos.

Ejemplos de nombres realistas:

feature/ajout-paiement-stripe
feature/dashboard-utilisateur
release/1.4.0
hotfix/correction-faille-login

Una buena convención de nombres es documentación gratuita: solo con el nombre de la rama, el equipo sabe de qué se trata.

🔧 Mini-ejercicio — Debes corregir de urgencia una falla de conexión en producción. ¿Qué prefijo de rama usas, y propone un nombre completo.

Git Flow es una estrategia estructurada introducida por Vincent Driessen en 2010. Se apoya en dos ramas permanentes (main y develop) y tres tipos de ramas temporales (feature, release, hotfix).

El ciclo típico:

1. Se parte de develop para crear una rama feature/*.
2. Una vez terminada, la feature se fusiona en develop.
3. Cuando hay suficientes funcionalidades listas, se crea una release/* para estabilizar.
4. La release se fusiona en main (y se etiqueta) y en develop.
5. ¿Un bug crítico en prod? Se crea un hotfix/* desde main, luego se fusiona en main y develop.

# Empezar una funcionalidad (sin la extensión git-flow)
git switch develop
git switch -c feature/panier

# ... trabajo + commits ...

git switch develop
git merge feature/panier
git branch -d feature/panier

Git Flow brilla con software entregado por versiones (apps móviles, software instalado). Para un sitio web desplegado 10 veces al día, se convierte en un freno.

GitHub Flow es una estrategia simple y ligera, pensada para el despliegue continuo. Una sola rama permanente: main. Todo lo demás pasa por ramas feature cortas y pull requests.

Las reglas de oro:

1. main es siempre desplegable.
2. Para cualquier trabajo, se crea una rama descriptiva desde main.
3. Se hace commit con regularidad y se abre una pull request (vista en la lección 03).
4. Tras la revisión y los tests en verde, se fusiona en main.
5. Se despliega de inmediato main.

git switch main
git pull
git switch -c feature/filtre-recherche
# ... commits ...
git push -u origin feature/filtre-recherche
# → abrir una Pull Request en GitHub

GitHub Flow es, con diferencia, el mejor punto de partida para un equipo moderno: suficiente estructura para colaborar, suficiente ligereza para ir rápido.

🔧 Mini-ejercicio — En GitHub Flow, escribe los dos comandos para partir de un main al día antes de crear tu rama de trabajo.

git switch main
git pull

El Trunk-Based Development (desarrollo sobre el tronco) lleva la simplicidad aún más lejos: todo el mundo integra su trabajo en una rama única (el trunk, es decir main) con mucha frecuencia — lo ideal es varias veces al día.

Principios clave:

• Las ramas de funcionalidad son minúsculas y viven menos de un día.
• Las funcionalidades no terminadas se ocultan detrás de feature flags (banderas) en lugar de vivir en ramas largas.
• La integración continua (CI) es obligatoria: cada commit dispara build + tests.

# Ciclo ultracorto
git switch main
git pull
# pequeña modificación...
git commit -am "Añadir el botón export"
git push      # integrado en el tronco unos minutos después

El peor enemigo de los equipos Git son las ramas que viven semanas. Cuanto más tarde se integra, más dolorosa es la fusión. El trunk-based lo resuelve integrando pronto y a menudo.

🔧 Mini-ejercicio — En Trunk-Based, ¿cómo integras una funcionalidad no terminada sin bloquear a los demás ni crear una rama larga?

No existe una estrategia universal: la buena elección depende del tipo de producto, de la madurez del equipo y de la frecuencia de despliegue.

Consejo: la mayoría de los equipos debería empezar por GitHub Flow. Ofrece el mejor compromiso simplicidad / seguridad. Se migra al trunk-based cuando la CI está madura, o a Git Flow solo si el producto impone versiones.

Question 1

¿Para qué sirve principalmente una rama Git?

a) Para guardar el repositorio en la nube

b) Para trabajar de forma aislada sin afectar el código estable

c) Para comprimir los archivos

d) Para borrar el historial

Question 2

¿Cuántas ramas permanentes usa Git Flow?

a) Una sola (main)

b) Dos (main y develop)

c) Ninguna

d) Una por desarrollador

Question 3

¿Qué estrategia es la más adecuada para un sitio web desplegado varias veces al día?

a) Git Flow

b) GitHub Flow o Trunk-Based

c) Ninguna rama en absoluto

d) Una rama por año

Question 4

En el Trunk-Based Development, ¿cómo se oculta una funcionalidad no terminada?

a) En una rama larga de varias semanas

b) Con un feature flag (bandera de funcionalidad)

c) Borrando el código cada noche

d) No se puede, hay que terminar todo de un golpe

Question 5

¿Qué prefijo de rama se usa para corregir un bug crítico directamente en producción?

a) feature/

b) release/

c) hotfix/

d) develop/

Corrigé

1. b — Una rama aísla el trabajo hasta la fusión, sin tocar el código estable.
2. b — Git Flow usa dos ramas permanentes: main y develop.
3. b — GitHub Flow y Trunk-Based encajan con el despliegue continuo; Git Flow es demasiado pesado.
4. b — Un feature flag oculta el código inacabado ya integrado en el tronco.
5. c — hotfix/ parte de main para un bug urgente en producción.

Consigna

Trabajas en un repositorio cuyo main es estable. Te piden añadir una página «Acerca de». Pon en práctica el GitHub Flow:

1. Parte de un main al día.
2. Crea una rama de funcionalidad bien nombrada.
3. Haz un commit que añada el archivo apropos.html.
4. Empuja la rama hacia el repositorio remoto para preparar una pull request.
5. Lista tus ramas para verificar.

Corrección

# 1. Partir de un main al día
git switch main
git pull origin main

# 2. Crear una rama descriptiva
git switch -c feature/page-apropos

# 3. Crear el archivo y luego hacer commit
echo "<h1>À propos</h1>" > apropos.html
git add apropos.html
git commit -m "Ajout de la page À propos"

# 4. Empujar la rama hacia el remoto
git push -u origin feature/page-apropos

# 5. Verificar las ramas
git branch

Resultado esperado:

* feature/page-apropos
  main

Siguiente etapa lógica: abrir una pull request en GitHub para hacer releer y fusionar este trabajo — es exactamente el objeto de la lección 03.

Puntos a recordar

1. Una rama aísla el trabajo sin afectar el código estable.
2. Tipos de ramas: main, develop, feature/, release/, hotfix/ — cada una con un rol.
3. Git Flow: estructurado, dos ramas permanentes, ideal para las versiones planificadas.
4. GitHub Flow: simple, una rama main + pull requests, perfecto para la web.
5. Trunk-Based: integración muy frecuente sobre el tronco, exige una CI sólida.
6. La elección depende del producto, del equipo y de la frecuencia de despliegue.

A continuación

Ahora que sabes organizar tus ramas, toca la lección 02 — Merge y rebase: cómo reunir esas ramas con limpieza y resolver los conflictos.