Borrar una rama en Git: local, remota y recuperación

Terminas de mergear una feature, sigues con la siguiente, y sin darte cuenta acumulas diez ramas viejas colgando en git branch. Todas huelen a basura, pero no las borras: te da respeto que “borrar” en Git suene a irreversible. Aquí te enseño a borrar una rama en Git, local y remota, entendiendo qué pasa por debajo para que no te cargues nada por error. Y cuando te lo cargues igualmente, cómo recuperarlo.

Para seguir este post necesitas saber crear y cambiar de rama, y haber hecho al menos un merge. Si eso todavía te suena raro, empieza por crear y cambiar de ramas en Git y por qué es un merge. Con eso, lo de abajo se entiende sin problema.

¿Qué pasa realmente cuando borras una rama en Git?

Borrar una rama elimina una referencia: un nombre que apunta a un commit concreto. Eso es una rama en Git. No es una carpeta con tus archivos ni una copia de tu código. Es una etiqueta, un post-it pegado sobre un commit que dice “aquí está la punta de esta línea de trabajo”.

Cuando borras la rama, quitas el post-it. Los commits que había debajo siguen ahí, guardados en la base de datos interna de Git, al menos durante un tiempo. Piensa en un tren de commits enganchados uno detrás de otro: la rama es solo el cartel de la estación final. Quitar el cartel no desengancha los vagones.

Esto cambia por completo el miedo a borrar. Casi nunca destruyes trabajo de verdad. Lo que sí puedes hacer es dejar unos commits “sin cartel”, y ahí es donde Git te avisa antes de dejarte hacerlo. Ese aviso es toda la lógica del comando de borrado.

Cómo borrar una rama local con git branch -d

El comando para borrar una rama local es git branch -d nombre-rama. La -d es de delete. Antes de borrar, conviene ver qué ramas ya están integradas en la que tienes activa:

# Lista las ramas cuyo trabajo ya está integrado en la rama actual
git branch --merged

Las que salgan en esa lista son seguras de borrar: su trabajo ya vive en otro sitio. Para borrar una:

# Borra la rama local 'feature/login' (solo si ya está mergeada)
git branch -d feature/login
# Salida: Deleted branch feature/login (was 3f8a2c1).

Ese 3f8a2c1 entre paréntesis es el hash del último commit de la rama. Git te lo enseña por si acaso. Guárdalo mentalmente: es tu billete de vuelta si te arrepientes.

Hay una regla importante: no puedes borrar la rama que tienes activa. Git se niega, porque sería como serrar la rama del árbol sobre la que estás sentada. Cámbiate a otra antes (por ejemplo con git switch main) y entonces bórrala.

¿Qué diferencia hay entre -d y -D?

La -d minúscula es la versión segura y la -D mayúscula es la versión que fuerza el borrado sin preguntar. Con -d, Git solo borra la rama si sus cambios ya están integrados en otra. Si intentas borrar una rama con commits que no están en ningún otro sitio, te frena:

$ git branch -d experimento/websockets
error: the branch 'experimento/websockets' is not fully merged
hint: If you are sure you want to delete it, run 'git branch -D experimento/websockets'

Ese aviso es la red de seguridad haciendo su trabajo: Git te frena antes de que pierdas algo. Git te está diciendo: “esta rama tiene trabajo que solo existe aquí, ¿seguro que lo quieres tirar?”. Si de verdad era un experimento fallido y quieres borrarlo, la -D mayúscula lo fuerza:

# Fuerza el borrado, tenga o no cambios sin integrar
git branch -D experimento/websockets

-D es exactamente el atajo de --delete --force. Regla mental sencilla: usa siempre -d primero. Si Git te deja, es que no había nada que perder. Si te frena, para y mira qué había en esa rama antes de sacar la -D.

Cómo borrar una rama remota

Borrar la rama en tu ordenador no la borra en el servidor. Son dos referencias distintas: la tuya local y la que vive en GitHub, GitLab o el remoto que uses. Para borrar la del remoto se usa git push:

# Borra la rama 'feature/login' del remoto llamado 'origin'
git push origin --delete feature/login

Lo primero que descoloca a mucha gente es que borrar sea un push. Tiene sentido si lo piensas: un push es “manda este cambio al servidor”, y borrar una rama es un cambio como otro cualquiera. Le estás diciendo al remoto “quita esta referencia de tu lado”.

La forma corta es git push origin -d feature/login. Hace lo mismo. Y ojo con la dirección: esto borra la rama en el servidor, pero deja intacta tu copia local, igual que borrar la local no toca el servidor. Si quieres que desaparezca de los dos lados, tienes que hacer las dos cosas.

Limpiar las ramas remotas fantasma con git fetch —prune

Cuando un compañero borra una rama en el servidor, tu Git no se entera solo. Sigue guardando una referencia local a esa rama remota, como origin/feature/login, aunque ya no exista en ningún sitio. Son ramas fantasma: aparecen en git branch -r pero apuntan a algo que ya murió.

Para limpiarlas:

# Actualiza desde origin y borra las referencias a ramas que ya no existen allí
git fetch --prune

--prune recorta las referencias remotas huérfanas. No toca tus ramas locales ni tu trabajo, solo pone al día tu mapa de lo que hay en el servidor. Es un comando inofensivo que conviene lanzar de vez en cuando para que git branch -r no se convierta en un cementerio.

Todo esto asume que borras lo que quieres borrar. ¿Y cuando la fastidias?

Borré una rama sin querer, ¿puedo recuperarla?

Casi siempre sí, y el rescate es más fácil de lo que parece. Aquí es donde entra git reflog, el registro que Git lleva de por dónde ha pasado tu HEAD (la posición actual) en las últimas semanas. Cada vez que cambias de rama, haces un commit o un merge, Git anota una línea en el reflog. Incluida la punta de la rama que acabas de borrar.

# 1. Busca en el historial reciente el último commit de la rama borrada
git reflog
# Salida (ejemplo):
#   3f8a2c1 HEAD@{4}: commit: añade login con OAuth
#   9d1b0e7 HEAD@{5}: checkout: moving from feature/login to main

# 2. Crea una rama nueva apuntando a ese commit
git branch feature/login 3f8a2c1

Con eso vuelves a poner el cartel sobre el mismo tren de commits. La rama resucita con todo su trabajo. Por eso decía al principio que borrar casi nunca destruye nada: mientras el commit siga en el reflog, hay camino de vuelta.

¿Cuánto tiempo tienes? Git conserva las entradas del reflog un buen rato antes de limpiarlas con gc (el recolector de basura). Por defecto son 90 días para los commits que siguen alcanzables y 30 días para los que quedan colgando, que es el caso de una rama borrada.^[1] No es “para siempre”, pero para un despiste de ayer tienes de sobra.

Errores comunes al borrar ramas

Intentar borrar la rama en la que estás. Es el tropiezo número uno. Git responde con error: cannot delete branch 'X' used by worktree at ... (esa rama está activa en otra carpeta de trabajo). La solución es de un paso: git switch main (o la rama que sea) y vuelve a borrar. No hay que forzar nada.

Confundir borrar local con borrar remota. Borras con git branch -d, entras en GitHub y la rama sigue ahí, tan pancha. No es un bug. La local y la remota son referencias separadas. Local se borra con git branch, remota con git push origin --delete. Dos comandos para dos sitios.

Sacar la -D sin mirar. La -D mayúscula fuerza el borrado saltándose la comprobación de “está mergeada”. Ese aviso está por algo. Si lo ignoras por costumbre, un día borrarás la única copia de dos horas de trabajo. Aun así, gracias al reflog casi siempre podrás recuperarla, pero es un susto que te ahorras leyendo el mensaje antes de forzar.

Creer que lo borrado se perdió para siempre. Este es el error mental que hace que la gente acumule diez ramas muertas: el miedo. Ya has visto que no. El reflog te cubre durante semanas. Borra con tranquilidad.

¿Qué comando uso? Tabla rápida

Comando	Qué borra	Cuándo usarlo	Riesgo
git branch -d rama	La rama local, solo si está mergeada	Tu opción por defecto para limpiar ramas ya integradas	Muy bajo: Git te frena si hay trabajo sin integrar
git branch -D rama	La rama local, esté mergeada o no	Un experimento fallido que de verdad quieres tirar	Medio: te saltas la comprobación, aunque el reflog te cubre
git push origin --delete rama	La rama en el servidor remoto	Cuando la feature ya está mergeada y no quieres dejarla en GitHub	Bajo: el trabajo suele seguir en tu local o ya mergeado
git fetch --prune	Nada real: solo referencias fantasma	Después de que se borren ramas en el remoto	Ninguno

Checklist antes de borrar una rama

• La rama que vas a borrar no es la que tienes activa (cámbiate con git switch antes)
• Has comprobado con git branch --merged que su trabajo ya está integrado
• Usas -d primero y solo pasas a -D si de verdad quieres descartar trabajo sin mergear
• Si quieres borrarla también del servidor, lanzas git push origin --delete
• Sabes que un despiste se arregla con git reflog + git branch nueva <hash>

Perderle el miedo a borrar ramas es uno de esos saltos pequeños que te hacen ir mucho más rápido con Git. Si quieres el recorrido completo, desde crear ramas hasta resolver conflictos de merge sin sudar, lo tienes ordenado paso a paso en la guía completa de ramas en Git. Y si prefieres aprenderlo practicando, el curso Git de cero a profesional recorre exactamente este flujo con ejercicios interactivos.

Un concepto nuevo cada semana

Suscribirme

Fuentes

1. Documentación oficial de git reflog (git-scm.com): tiempos de expiración por defecto del reflog (90 días para entradas alcanzables, 30 para las no alcanzables como una rama borrada).

Preguntas Frecuentes

¿Borrar una rama borra sus commits?

No de inmediato. Borras la referencia, no los commits. Si esos commits ya estaban en otra rama, no pasa nada en absoluto. Si eran exclusivos de la rama borrada, quedan “colgando” pero recuperables durante semanas vía git reflog, hasta que Git los limpie con su recolector de basura.

¿Puedo borrar main o master?

Técnicamente Git te deja borrar cualquier rama que no sea la activa, pero casi nunca querrás borrar main. Es tu línea principal de trabajo y muchos remotos la protegen para que nadie la borre por accidente. Si de verdad crees que necesitas hacerlo, para y comprueba antes qué trabajo depende de ella.

¿Cómo borro varias ramas a la vez?

Puedes pasar varios nombres al mismo comando: git branch -d rama1 rama2 rama3. Si quieres borrar en bloque todas las que ya estén mergeadas, algunos combinan git branch --merged con un filtro para pasárselas a git branch -d, pero al principio ve una a una: es más lento y mucho más difícil borrar algo por error.

¿Borrar la rama local borra la remota?

No. Son dos referencias independientes. git branch -d borra la copia de tu ordenador y git push origin --delete borra la del servidor. Puedes borrar una y dejar la otra viva tranquilamente. Para que la rama desaparezca de los dos sitios tienes que lanzar los dos comandos.

¿Cuánto tiempo puedo recuperar una rama con reflog?

Por defecto tienes unos 30 días para los commits que quedan sin ninguna rama que los alcance, que es justo el caso de una rama borrada. Es margen de sobra para un despiste normal. Si sabes que la fastidiaste, recupérala cuanto antes con git reflog y no lo dejes semanas.