Git rebase -i es uno de los comandos que más intimidan a desarrolladores junior —y, según el autor, también a muchos seniors—, pero su funcionamiento real es bastante más sencillo de lo que sugiere su fama. El artículo es una guía didáctica pensada para desmitificar el rebase interactivo y animar a usarlo con confianza.
¿Qué es y cómo funciona? Al ejecutar git rebase -i HEAD~4, Git abre un archivo de texto con la lista de los últimos commits; cada línea es una instrucción (pick, reword, squash, fixup, drop) que el desarrollador edita a voluntad. Antes de aplicar nada, Git muestra un plan: nada se ejecuta hasta guardar el archivo. Si uno se arrepiente a mitad de camino, git rebase --abort revierte la rama a su estado original.
¿Es peligroso perder trabajo? No tanto como se cree, por tres motivos: se puede abortar en cualquier momento; el rebase no destruye commits sino que crea otros nuevos y mueve el puntero de la rama, dejando los antiguos intactos en la base de objetos hasta la recolección de basura; y el reflog guarda un historial completo de movimientos, lo que permite restaurar el estado anterior con git reset --hard HEAD@{n}. Como red de seguridad adicional, se puede crear una rama backup-before-rebase antes de empezar.
¿Y los conflictos? Aparecen sobre todo al reordenar commits o rebasar sobre una rama main actualizada, y se resuelven igual que en un merge —archivo por archivo, con git add y git rebase --continue—. Al tratarse de un commit cada vez, el autor argumenta que resolverlos aquí resulta más fácil que en una fusión tradicional.
Buenas prácticas: entender bien qué hace cada comando antes de lanzarlo, rebasar solo sobre ramas de trabajo propias antes de la revisión y, al publicar, preferir git push --force-with-lease frente a --force, ya que el primero aborta si alguien más ha subido cambios mientras tanto. El rebase interactivo, concluye, es una herramienta básica que cualquier desarrollador debería dominar sin temor.