Borrar un commit del historial de Git es una de esas tareas que parecen simples hasta que toca hacerlo de verdad. La diferencia entre eliminar un commit, deshacer cambios o reescribir el historial puede tener consecuencias importantes, sobre todo si ya has compartido tu rama con otras personas.
En este artículo vamos a ver cuándo conviene borrar un commit, qué comandos usar en cada caso y qué riesgos debes tener en cuenta antes de tocar el historial. Si ya dominas conceptos como git log o cómo deshacer el último commit sin perder cambios, aquí darás el siguiente paso.
No todos los casos se resuelven igual
Cuando alguien dice “quiero borrar un commit”, puede estar hablando de varias situaciones distintas. Tal vez quiere eliminar el último commit porque contiene un error, quizá necesita quitar un commit antiguo que nunca debió existir, o simplemente desea limpiar una rama local antes de subirla.
La clave está en distinguir entre historial local e historial remoto. Si el commit solo existe en tu equipo, puedes reescribir la historia con libertad. Si ya lo has publicado con git push, la cosa cambia, porque otros desarrolladores pueden haber basado trabajo en ese mismo punto.
Elimina, revierte o reescribe
Git ofrece varias herramientas para actuar sobre un commit, pero no hacen exactamente lo mismo. git reset mueve la referencia de la rama y puede hacer desaparecer commits del historial visible. git revert crea un nuevo commit que deshace otro anterior sin borrarlo. Y rebase interactivo permite reorganizar o eliminar commits concretos de una cadena.
Elegir bien el método evita conflictos innecesarios y reduce el riesgo de perder trabajo. Si todavía no tienes clara la mecánica de las ramas, te ayudará revisar qué son las ramas en Git y cómo funcionan.
Cómo borrar el último commit con git reset
Si el commit que quieres borrar es el más reciente y todavía no lo has compartido, git reset suele ser la opción más directa. Este comando mueve el puntero de la rama a un commit anterior. Dependiendo del modo que uses, puedes conservar o descartar los cambios del directorio de trabajo.
Los dos modos más habituales son –soft y –hard. El primero mantiene los cambios preparados para volver a commitarlos. El segundo elimina los cambios por completo, así que conviene usarlo con mucha cautela.
# Borra el último commit pero conserva los cambios en staging
git reset --soft HEAD~1
# Borra el último commit y descarta los cambios asociados
git reset --hard HEAD~1
En general, HEAD~1 significa “el commit anterior”. Si quieres revisar el estado antes de ejecutar nada, consulta primero git status y valida qué archivos cambiarán de estado.
Cuándo usar cada variante
Usa –soft si quieres corregir el mensaje del commit, añadir archivos olvidados o rehacer el commit con más precisión. Usa –hard solo cuando estés seguro de que no necesitas recuperar nada de ese punto. En entornos con trabajo compartido, esta es la opción más delicada.
Si después de hacer reset quieres volver a revisar qué cambió, puedes apoyarte en git diff para inspeccionar el contenido antes de crear un nuevo commit.
Cómo borrar un commit antiguo con rebase interactivo
Cuando el commit que quieres eliminar no es el último, sino uno más antiguo dentro de una serie de commits locales, la herramienta más flexible suele ser git rebase -i. Este flujo te permite abrir una lista editable de commits y decidir si los conservas, los modificas, los fusionas o los eliminas.
# Abre los últimos 3 commits para edición
git rebase -i HEAD~3
# En el editor, cambia 'pick' por 'drop' en el commit que quieras eliminar
# Luego guarda y cierra el editor
La palabra clave drop indica a Git que retire ese commit del historial reescrito. En algunas versiones y configuraciones también puedes simplemente borrar la línea o cambiar pick por la acción correspondiente, según el editor y el flujo que estés usando.
Este método es muy útil para limpiar commits de prueba, eliminar cambios intermedios innecesarios o reorganizar una rama de trabajo antes de integrarla. Si quieres profundizar en esta técnica, puede ayudarte el artículo sobre cómo reescribir el historial con git rebase.
Ventajas y riesgos de rebase
La gran ventaja de rebase interactivo es que ofrece un control fino sobre la historia de la rama. La desventaja es la misma que lo hace potente: estás reescribiendo commits, y eso puede provocar problemas si ya compartiste esa rama con otras personas.
Si detectas conflictos durante el proceso, tendrás que resolverlos manualmente. En ese caso, te interesará repasar cómo resolver conflictos de fusión en Git, porque la lógica de resolución es muy parecida.
Qué pasa si el commit ya está en remoto
Este es el punto más importante. Si el commit ya se ha publicado en un repositorio remoto, borrar el historial local no lo elimina automáticamente del servidor. Para reflejar la nueva historia tendrás que forzar la actualización con git push –force o una variante equivalente, aunque esta práctica debe usarse con extrema prudencia.
Forzar un push puede sobrescribir trabajo ajeno si otras personas han sincronizado su copia. Por eso, en ramas compartidas suele ser más seguro usar git revert en lugar de borrar commits. Si quieres entender bien cuándo conviene cada enfoque, revisa también cómo revertir un commit con git revert.
Recomendación práctica para equipos
En equipos de desarrollo, la regla general es evitar reescribir historial en ramas compartidas, salvo que exista coordinación clara. En ramas personales o de preparación, en cambio, borrar commits con reset o rebase puede ser perfectamente razonable.
Si trabajas con flujos de colaboración más estructurados, conviene entender cómo encajan estas operaciones con tus ramas, merges y despliegues. Los artículos sobre git merge y Git Flow vs GitHub Flow aportan contexto útil para tomar mejores decisiones.
Cómo recuperar un commit borrado por error
Si borras un commit y luego te arrepientes, no todo está perdido. Git conserva referencias temporales que muchas veces permiten recuperar el estado anterior. La herramienta más conocida para ello es git reflog, que registra movimientos recientes de HEAD y de las ramas.
Este recurso es especialmente útil cuando has usado reset –hard o un rebase agresivo y quieres volver atrás. Si quieres dominar este tipo de rescate, merece la pena leer cómo recuperar commits borrados con git reflog.
Antes de tocar el historial, haz una copia mental del estado
Un hábito sencillo que evita desastres es mirar siempre el contexto: verifica en qué rama estás, qué commits hay encima, qué cambios están sin guardar y si la rama ya se publicó. Esa pequeña revisión reduce muchísimo los errores.
También es buena idea trabajar con commits pequeños y mensajes claros. Así, si necesitas borrar uno, el impacto será menor y el historial resultará más fácil de interpretar. Puedes reforzar este hábito con las buenas prácticas para escribir mensajes de commit en Git.
Resumen rápido de comandos
Si solo quieres una guía breve, aquí tienes la idea central: git reset para borrar commits locales, git rebase -i para eliminar commits concretos de una secuencia y git revert para deshacer cambios sin reescribir la historia.
La elección correcta depende de tres factores: si el commit ya se compartió, si forma parte de una rama estable y si necesitas conservar trazabilidad. En Git, borrar no siempre significa desaparecer; a menudo significa reescribir o compensar.
Fuentes y lecturas recomendadas
Tutoriales de Git en Atlassian
Deja una respuesta