Recuperar una rama borrada en Git
Los bloques son casos distintos, no un único script. Elige el que encaja con tu repositorio. Sustituye ramas, rutas y VERIFIED_COMMIT antes de usarlos. Los comandos de cancelación solo corresponden a su operación activa; no ejecutes ambas alternativas.
Respuesta breve
Borrar una rama elimina su referencia, no necesariamente sus commits. Busca su último commit conservado y crea una rama nueva que lo nombre.
Ejemplo y condiciones
Necesitas el commit correcto y sus objetos disponibles. El mensaje de borrado puede incluir su SHA; guárdalo y compruébalo antes de actuar.
Inspecciona antes de cambiar
Lee el reflog de HEAD y el historial candidato. Al borrar una rama se elimina también su reflog; el registro de HEAD puede conservar movimientos relevantes.
git reflog --date=iso
git show VERIFIED_COMMIT
git log -5 --oneline VERIFIED_COMMITConserva una referencia o checkout separado
Usa git branch rescue/deleted-branch VERIFIED_COMMIT para dar nombre al commit sin cambiar de rama. No necesitas sobrescribir el directorio de trabajo.
git branch rescue/deleted-branch VERIFIED_COMMITPrimer flujo
Verifica con git show y git log que el candidato contiene la punta y el historial deseados. Después recrea el nombre original, si está libre.
Elige deliberadamente la otra opción
Si existía una rama remota, confirma que su referencia sigue allí antes de hacer fetch y recrear la rama local. Haberla subido una vez no garantiza su conservación.
Límites y excepciones
Una copia nueva no trae tu reflog local. La caducidad del reflog y el pruning de objetos son políticas separadas y configurables; evita una limpieza agresiva durante la recuperación.
git ls-remote --heads origin my-branchConflictos y limpieza
Si falta una referencia, git fsck --full --no-reflogs --unreachable puede localizar commits retenidos. Inspecciona cada candidato; el comando no sabe qué rama querías.
git fsck --full --no-reflogs --unreachableVerifica el resultado
Comprueba el historial de la rama recreada y su estado. La recuperación de commits no restaura cambios de archivos que nunca se guardaron en un commit.
git log -5 --oneline rescue/deleted-branch
git status --shortPreguntas habituales
El nombre perdido no es una copia de seguridad. Si ya no existe el objeto, busca otra copia, un colaborador o una referencia remota realmente disponible.
Revisa la operación en FluxGit
FluxGit puede proteger el borrado desde la app. El Ref journal habilitado registra cambios de referencias cuando se ejecuta su hook instalado; los bypasses y otras implementaciones Git quedan fuera de esa cobertura.
Documentación oficial de Git
Recuperar una rama de Git borrada con reflog
Recupera una rama local borrada recientemente encontrando su commit conservado y creando una rama nueva. Verás reflog y la Safety Timeline de FluxGit en un repositorio de prueba, y cuándo el hook instalado del Ref journal puede registrar cambios de referencias desde la línea de comandos Git.
Ver en YouTube — abre una pestaña nueva
Grabado en un repositorio de prueba. Voz en inglés y subtítulos en español. La recuperación exige objetos de commit conservados y registros disponibles del reflog o del diario; el Ref journal no guarda archivos sin commit.
Leer la transcripción de la narración
- Borraste una rama con trabajo dentro: git branch guion D mayúscula, dos commits que nunca se fusionaron en ningún sitio. Así se recuperan.
- En FluxGit la rama ya no aparece en la lista.
- Por esto no se ha perdido. Una rama es una etiqueta. git branch guion D mayúscula borra la etiqueta, pero los dos commits siguen en el repositorio, sin ninguna rama que los señale. El reflog todavía los recuerda. Pon una rama en el último y vuelven los dos.
- Abre la Safety Timeline. Muestra el reflog en frases sencillas.
- Find a lost commit: escribe parte de su mensaje. Una coincidencia, el último commit de la rama borrada.
- Create branch here. Una rama de recuperación apunta a ese commit, y nada más se mueve.
- Los dos commits vuelven a estar en el grafo.
- Activa el Ref journal para este repositorio.
- Cuando se ejecuta el hook de Git instalado, FluxGit puede registrar eliminaciones de ramas realizadas desde la línea de comandos Git, incluidos los comandos de terminal o de agentes.
- No cubre los casos que omiten el hook ni otras implementaciones de Git.
- Registra referencias, no archivos sin commit.
- La recuperación sigue requiriendo que existan los objetos de commit.
- En la terminal: git reflog, busca el commit y luego git branch con el nombre antiguo y ese commit.
- Resumen. Una rama borrada es una etiqueta perdida; el reflog todavía encuentra los commits. Siguiente lección: cuando un agente de IA borra tu código.