Ramas en Git: aislamiento de trabajo y evolución segura

Qué es una rama en Git (de verdad)

En Git, una rama no es una “carpeta” ni una copia completa del proyecto. Una rama es, principalmente, un puntero con nombre que apunta a un commit específico. Cuando haces nuevos commits estando en esa rama, el puntero se mueve hacia adelante para apuntar al commit más reciente.

Esto habilita el trabajo paralelo: puedes tener una rama para desarrollar una funcionalidad nueva, otra para corregir un bug, y mantener una rama principal estable. Cada línea de trabajo avanza con sus propios commits sin interferir con las demás.

HEAD: dónde estás parado

Además de las ramas, Git usa HEAD para indicar “en qué referencia estás actualmente”. Normalmente HEAD apunta a una rama (por ejemplo, main). Si cambias de rama, HEAD cambia con ella.

Ver ramas y entender el estado actual

Para listar ramas locales y ver cuál está activa:

git branch

La rama actual aparece marcada con *. Para ver también ramas remotas:

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

git branch -a

Para ver a qué commit apunta cada rama (útil para “ver el puntero”):

git show-ref --heads

Crear, cambiar y eliminar ramas

Crear una rama

Crea una rama nueva desde el commit actual (no te cambia de rama):

git branch feature/login-form

Crear y cambiarte en un solo paso (recomendado):

git switch -c feature/login-form

Si tu Git es antiguo, el equivalente es:

git checkout -b feature/login-form

Cambiar de rama

git switch main

Si tienes cambios sin commitear, Git puede impedir el cambio si esos cambios entrarían en conflicto con la otra rama. En ese caso, o bien commiteas, o bien guardas temporalmente con git stash (si ya lo viste en tu curso, úsalo como herramienta de apoyo).

Eliminar una rama

Eliminar una rama local que ya fue integrada (Git te protege):

git branch -d feature/login-form

Forzar eliminación (peligroso si no integraste y perderías referencia fácil a esos commits):

git branch -D feature/login-form

Eliminar una rama remota (por ejemplo en origin):

git push origin --delete feature/login-form

Convenciones de nombres: claridad y orden

Nombrar ramas bien reduce confusión y acelera revisiones. Una convención simple y común es usar prefijos por tipo de trabajo:

• feature/: nuevas funcionalidades (ej. feature/login-form)
• fix/: correcciones de bugs (ej. fix/null-pointer-checkout)
• chore/: tareas de mantenimiento (ej. chore/update-deps)

Buenas prácticas al nombrar:

• Usa minúsculas y guiones: feature/user-profile
• Evita nombres genéricos: feature/test no dice nada
• Si usas tickets, inclúyelos: fix/1234-payment-timeout

Flujos comunes: rama principal estable + ramas de trabajo

Un flujo típico para principiantes (y muy usado en equipos) es:

• Rama principal estable: main (o master en repos antiguos). Debe estar siempre en estado “publicable”.
• Ramas de trabajo: se crean desde main para desarrollar o corregir algo sin romper la estabilidad.

La idea es simple: main avanza con cambios ya revisados/integrados; el trabajo en progreso vive en ramas separadas.

Escenario 1: desarrollar una funcionalidad en rama separada

Objetivo: implementar una pantalla de login sin afectar la estabilidad de main.

Paso a paso

1. Asegúrate de estar en main y actualizado (si trabajas con remoto):

   git switch main

   Si tienes remoto configurado:

   git pull origin main

2. Crea una rama de funcionalidad y cámbiate:

   git switch -c feature/login-form

3. Trabaja normalmente: edita archivos y crea commits en esa rama. Verifica dónde estás:

   git branch

4. En cualquier momento puedes comparar qué cambió respecto a main:

   git diff main..feature/login-form

5. Cuando termines, vuelve a main:

   git switch main

6. Integra la rama de funcionalidad en main (merge):

   git merge feature/login-form

   Si no hubo divergencia compleja, puede ser un merge rápido (fast-forward). Si hubo cambios en ambos lados, Git puede crear un commit de merge o pedirte resolver conflictos.

7. Elimina la rama local si ya no la necesitas:

   git branch -d feature/login-form

Escenario 2: bug urgente (hotfix) y volver a la rama principal

Situación: estás trabajando en una funcionalidad, pero aparece un bug crítico en producción. Necesitas corregirlo sin mezclar trabajo incompleto.

Meta del flujo

• Dejar tu trabajo en la rama de feature intacto.
• Crear una rama de fix desde main.
• Aplicar la corrección y volver a main con el bug resuelto.

Paso a paso

1. Si estás en tu rama de feature, verifica:

   git branch

2. Vuelve a main (si tienes cambios sin commitear y Git no te deja, primero commitea o guarda temporalmente):

   git switch main

3. Actualiza main desde remoto si aplica:

   git pull origin main

4. Crea una rama de corrección:

   git switch -c fix/urgent-checkout-crash

5. Aplica la corrección y crea el commit en la rama de fix.

6. Vuelve a main e integra la corrección:

   git switch main

   git merge fix/urgent-checkout-crash

7. Elimina la rama de fix si ya se integró:

   git branch -d fix/urgent-checkout-crash

8. Regresa a tu rama de feature para continuar:

   git switch feature/login-form

Interpretar gráficos de historial: ver ramas, merges y divergencias

Para “leer” el historial con ramas, lo más útil es un log en forma de grafo:

git log --oneline --graph --decorate --all

Qué significa cada parte:

• --graph: dibuja líneas ASCII mostrando bifurcaciones y merges.
• --decorate: muestra etiquetas como nombres de ramas apuntando a commits.
• --all: incluye todas las ramas (si no, solo verías la actual).

Ejemplo mental de lectura

Imagina que ves algo como esto:

*   a12f9c0 (HEAD -> main) Merge branch 'feature/login-form' into main|\| * 91bd2aa (feature/login-form) Ajusta validación del formulario| * 7c1a110 UI inicial de login|/| * 55aa001 Corrige typo en README* 1f02b3c Base estable

Cómo interpretarlo:

• main apunta al commit de merge a12f9c0.
• feature/login-form apuntaba a 91bd2aa antes de integrarse (puede seguir existiendo o ya haberse borrado).
• Las líneas |\ y |/ muestran la bifurcación y el reencuentro (merge).

Detectar ramas divergentes y entender “quién está adelante”

Una rama está divergente cuando ambas (por ejemplo main y tu rama de trabajo) tienen commits que la otra no tiene. Esto suele pasar si main avanzó mientras tú trabajabas en tu rama.

Ver diferencias de commits entre ramas

Commits que están en tu rama pero no en main:

git log --oneline main..feature/login-form

Commits que están en main pero no en tu rama:

git log --oneline feature/login-form..main

Resumen rápido de ahead/behind

git rev-list --left-right --count main...feature/login-form

La salida suele ser dos números: A B, donde A es cuántos commits tiene main que tu rama no tiene, y B cuántos commits tiene tu rama que main no tiene.

Señales típicas de divergencia en el grafo

• Ves dos “líneas” que se separan y no vuelven a unirse.
• main apunta a un commit distinto al de tu rama, y ambos tienen historia reciente propia.

Práctica guiada: mini-laboratorio de ramas (sin remoto)

Ejercicio para interiorizar punteros y divergencia en un repo local:

1. Crea una rama de feature y haz un commit:

   git switch -c feature/demo-branches

2. Haz cambios y commitea (1 o 2 commits).

3. Vuelve a main y haz un commit distinto (simula que el equipo avanzó):

   git switch main

4. Haz un cambio pequeño y commitea.

5. Ahora mira el grafo:

   git log --oneline --graph --decorate --all

6. Detecta divergencia comparando commits:

   git log --oneline main..feature/demo-branches

   git log --oneline feature/demo-branches..main

7. Integra la rama (merge) y vuelve a mirar el grafo:

   git merge feature/demo-branches