Ramas en Git: qué es un branch, cómo hacer merge y conflictos

Una rama (branch) en Git es una línea de desarrollo independiente. Te permite trabajar en algo nuevo sin tocar el código que ya funciona, y fusionarlo cuando esté listo.

Es la característica que convierte a Git en algo más que un historial de cambios, y la que hace posible que varias personas trabajen a la vez sin pisarse.

Para qué sirven

Imagina que tu proyecto funciona y quieres añadir una función nueva que tardará una semana. Sin ramas tienes dos opciones malas: tocar el código que funciona y arriesgarte a romperlo, o esperar a terminar antes de guardar nada.

Con ramas creas una línea paralela. Trabajas ahí, cometes errores, pruebas cosas. Mientras tanto la rama principal sigue intacta y lista para desplegar. Si mañana surge un fallo urgente, vuelves a la principal, lo arreglas, lo despliegas y regresas a lo tuyo sin haber perdido nada.

Cómo funcionan por dentro

Esta es la parte que hace que todo encaje: una rama en Git no es una copia de los archivos. Es simplemente un puntero que apunta a un commit.

Por eso crear una rama es instantáneo, aunque el proyecto tenga miles de archivos: Git solo crea un puntero de unos pocos bytes. Es la diferencia principal con sistemas de control de versiones más antiguos, donde ramificar significaba duplicar el proyecto entero.

Cuando haces un commit estando en una rama, ese puntero avanza al commit nuevo. La rama main se queda donde estaba.

Comandos básicos

# Ver las ramas (la actual lleva un asterisco)
git branch

# Crear una rama
git branch nueva-funcion

# Cambiar a otra rama
git checkout nueva-funcion

# Crear y cambiar de una vez (lo habitual)
git checkout -b nueva-funcion

# Sintaxis moderna, más clara
git switch -c nueva-funcion

# Volver a la principal
git switch main

# Borrar una rama ya fusionada
git branch -d nueva-funcion

Fíjate en la diferencia entre -d y -D: la minúscula solo borra si la rama ya se fusionó; la mayúscula fuerza el borrado y puedes perder trabajo.

Un flujo de trabajo normal

# 1. Partimos de main actualizada
git switch main
git pull

# 2. Creamos la rama para lo nuevo
git switch -c funcion-login

# 3. Trabajamos y vamos guardando
git add .
git commit -m "Añade formulario de login"
git commit -m "Valida credenciales en servidor"

# 4. Subimos la rama al repositorio remoto
git push -u origin funcion-login

# 5. Cuando está lista, la fusionamos
git switch main
git pull
git merge funcion-login

# 6. Limpiamos
git branch -d funcion-login

Qué es un merge

Fusionar es integrar los cambios de una rama en otra. Git lo hace de dos formas distintas según la situación.

Fast-forward

Si main no ha cambiado desde que creaste tu rama, Git simplemente adelanta el puntero. No crea nada nuevo: la historia queda en línea recta.

Merge de tres vías

Si main avanzó por su cuenta mientras tú trabajabas, Git compara tres puntos: el origen común, el final de tu rama y el final de main. Con eso construye un commit de fusión que une ambas historias.

Ese commit extra a veces molesta a quien quiere una historia limpia, y de ahí viene el debate con rebase.

Merge o rebase

rebase hace algo distinto: en lugar de unir las dos historias, reescribe tus commits como si los hubieras hecho a partir del estado actual de main.

git switch funcion-login
git rebase main

La regla de oro del rebase: nunca lo hagas sobre commits que ya compartiste con otras personas. Como reescribe la historia, quien tenga esos commits en su copia se va a encontrar un lío difícil de deshacer.

Rebase en tu rama local antes de fusionar: bien. Rebase en main: mala idea.

Resolver conflictos

Un conflicto ocurre cuando dos ramas modificaron las mismas líneas del mismo archivo. Git no puede decidir cuál vale y te pide que lo hagas tú.

No es un error ni significa que algo salió mal: es parte normal del trabajo en equipo.

Al fusionar verás algo así en el archivo:

<<<<<<< HEAD
const titulo = "Panel de control";
=======
const titulo = "Dashboard";
>>>>>>> funcion-login

Lo que hay entre <<< y === es tu versión actual. Lo que va entre === y >>> es la versión que entra.

Cómo resolverlo:

1. Abre el archivo y decide qué versión queda. Puedes elegir una, la otra, o escribir algo nuevo combinando ambas.
2. Borra las tres líneas de marcadores (<<<, ===, >>>). Si se quedan, el código no compila.
3. Marca el conflicto como resuelto y completa la fusión:

git add archivo-en-conflicto.js
git commit

Si te arrepientes a mitad:

git merge --abort

Vuelve todo al estado anterior, como si no hubieras intentado nada.

Cómo evitar conflictos

• Ramas cortas. Una rama de dos días genera pocos conflictos; una de tres semanas, muchos.
• Actualiza a menudo. Trae los cambios de main a tu rama cada día en vez de esperar al final.
• Reparte el trabajo por archivos. Si dos personas tocan el mismo fichero a la vez, el conflicto está garantizado.
• Commits pequeños y frecuentes. Facilitan ver qué cambió y por qué.

Convención de nombres

Un esquema habitual en equipos:

• main — el código en producción
• develop — integración de lo que viene
• feature/nombre — funciones nuevas
• fix/nombre — corrección de errores
• hotfix/nombre — urgencias en producción

Preguntas frecuentes

¿Cuántas ramas puedo tener?
Las que quieras. Como son punteros, no ocupan prácticamente nada.

¿Se pierde algo al borrar una rama fusionada?
No. Los commits ya están en la rama de destino. Solo desaparece el puntero.

¿Qué diferencia hay entre checkout y switch?
switch es más reciente y hace solo una cosa: cambiar de rama. checkout hace eso y varias cosas más, lo que lo vuelve confuso. Usa switch.

¿Puedo recuperar una rama borrada por error?
Normalmente sí, con git reflog, que guarda el historial de movimientos. Busca el identificador del último commit y crea la rama de nuevo desde ahí.

¿Quieres dominar Git y el trabajo en equipo? En nuestro catálogo de cursos técnicos tienes formación desde cero, con acceso inmediato y de por vida.