Flujo de trabajo con ramas de características

Descripción general

El flujo de trabajo con ramas de características es la forma más común en que los equipos colaboran con Git. La regla es simple: todo el desarrollo ocurre en ramas dedicadas, nunca directamente en main. Cada nueva característica, corrección o experimento obtiene su propia rama, y la rama main solo recibe trabajo terminado y revisado. Esto mantiene main estable y lista para publicar en todo momento.

La idea central

Dado que el trabajo está aislado en ramas, varias personas pueden construir diferentes características en paralelo sin interferirse. main actúa como la única fuente de verdad para el código listo para producción. Una rama es una unidad de trabajo enfocada que tiene un inicio claro (creada desde main) y un final claro (fusionada de vuelta en main).

Es importante destacar que una rama en Git es económica: es solo un puntero móvil hacia un commit, no una copia de tus archivos. Crearla es instantáneo y usa casi nada de espacio en disco, lo que hace que crear una rama por tarea sea completamente práctico.

Nomenclatura de ramas

Un esquema de nombres consistente hace que las ramas se documenten solas. La mayoría de los equipos prefijan la rama con su tipo y hacen referencia a la tarea en la que se trabaja:

feature/login-form
feature/W3-142-checkout-page
fix/null-pointer-on-logout
chore/upgrade-eslint

La barra es solo una convención: Git trata feature/login-form como un único nombre de rama, aunque permite que las herramientas agrupen las ramas por prefijo. Evita espacios y mayúsculas para que los nombres sean fáciles de escribir.

Un ejemplo paso a paso

El flujo de trabajo es un ciclo corto y repetible: crear una rama desde main, trabajar, hacer push, revisar, fusionar y limpiar.

1. Crear la rama desde un main actualizado

Siempre comienza desde el main más reciente para que tu rama se base en el código actual:

git switch main
git pull
git switch -c feature/login-form

git switch -c crea la rama y la activa en un solo paso (el equivalente más antiguo es git checkout -b). Consulta git switch para ver el comando completo.

2. Realizar el trabajo, haciendo commits sobre la marcha

Haz commits en pasos pequeños y lógicos en lugar de un commit gigante al final: los commits pequeños son más fáciles de revisar y de deshacer:

git add login.html login.js
git commit -m "Add login form markup and validation"

Prefiere indicar archivos específicos antes que usar git add . para no hacer commit accidentalmente de cambios no relacionados. Lee más sobre cómo crear buenos commits en git commit.

3. Hacer push de la rama

Haz push para que tus compañeros puedan ver tu trabajo y para poder abrir un pull request. El flag -u vincula tu rama local con la remota, de modo que luego basta con escribir git push:

git push -u origin feature/login-form

Consulta git push para entender en detalle qué hace -u (--set-upstream).

Revisión y fusión

En una plataforma de alojamiento como GitHub o GitLab, abres un pull request (PR), llamado merge request en GitLab. Aquí es donde los compañeros revisan el diff, dejan comentarios y aprueban. Los checks de integración continua (CI) suelen ejecutar el conjunto de pruebas contra la rama automáticamente. Una vez que el PR está aprobado y los checks están en verde, la rama se fusiona en main.

Estas plataformas ofrecen tres estrategias de fusión comunes:

• Merge commit — conserva cada commit de la rama más un commit de fusión. Mantiene el historial completo, pero puede ser ruidoso.
• Squash and merge — colapsa todos los commits de la rama en un único commit ordenado en main. Es popular porque main se mantiene limpia y cada característica es una sola entrada.
• Rebase and merge — reproduce los commits de la rama sobre main sin commit de fusión, dando un historial lineal.

Limpiar después de fusionar

Una vez fusionada la rama, elimínala localmente y en el remoto para que el repositorio no se llene de ramas obsoletas:

git switch main
git pull
git branch -d feature/login-form        # delete the local branch
git push origin --delete feature/login-form   # delete the remote branch

git branch -d se niega a eliminar una rama que no ha sido fusionada, lo que te protege de perder trabajo. (Usa -D para forzar la eliminación cuando estés seguro.)

Mantener una rama actualizada

Si main avanza mientras trabajas, incorpora esos cambios en tu rama para que la fusión eventual sea fluida y los conflictos aparezcan pronto. Tienes dos opciones:

# Option A — merge main into your branch (keeps history as-is)
git switch feature/login-form
git merge main

# Option B — rebase your branch onto the latest main (linear history)
git switch feature/login-form
git rebase main

Fusionar es no destructivo y seguro para ramas compartidas, pero añade commits de fusión. Rebasear produce un historial más limpio y lineal, pero reescribe los commits de tu rama, así que evita rebasear una rama que otros ya hayan descargado. La regla general: rebasea tu propia rama privada, fusiona todo lo que sea compartido.

Resolver conflictos

Cuando dos ramas modifican las mismas líneas, la fusión o el rebase se detiene y te pide que resuelvas el conflicto. Git marca las regiones en conflicto en los archivos afectados; tú las editas, luego las agregas al stage y continúas. El proceso completo está explicado en Resolución de conflictos de fusión.

Guardar trabajo en progreso

Si necesitas cambiar de rama pero no estás listo para hacer commit, git stash guarda temporalmente tus cambios no confirmados para que puedas moverte libremente y recuperarlos más tarde:

git stash            # set current changes aside
git switch main      # do something urgent
git switch feature/login-form
git stash pop        # bring the changes back

Ventajas y desventajas

El flujo de trabajo con ramas de características es popular porque es fácil de entender, se integra de forma natural con los pull requests y la revisión de código, y mantiene main lista para publicar en todo momento.

Su principal riesgo son las ramas de larga duración: cuanto más tiempo vive una rama, más diverge de main y más difícil se vuelve la fusión eventual ("infierno de fusiones"). Para evitarlo:

• Mantén las ramas pequeñas y de corta duración: idealmente fusionadas en uno o dos días.
• Incorpora main en tu rama (o rebasea) con regularidad, no solo al final.
• Divide las características grandes en varias ramas más pequeñas que se fusionen de forma independiente.
• Nunca hagas commit directamente en main: eso anula el propósito del flujo de trabajo.

Cuando los equipos necesitan ramas de lanzamiento, ramas de hotfix y un proceso de promoción estricto además de esto, suelen adoptar un modelo más completo como Git Flow o el desarrollo basado en trunk, pero la rama de características es el bloque de construcción que subyace a todos ellos.

Práctica