Un historial Git limpio no es coquetería: es lo que hace que una revisión sea legible y un git bisect eficaz. El rebase interactivo ( git rebase -i ) es la herramienta para reescribir una rama antes de publicarla — fusionar, renombrar, reordenar, eliminar commits. Aquí tienes cómo manejarlo sin quemarte.

Abrir el todo

git rebase -i toma una base : todos los commits que vienen después de ella se vuelven editables. Generalmente se apunta a los N últimos commits de la rama actual.

Git abre entonces una lista, del más antiguo (arriba) al más reciente (abajo). Cada línea comienza con un comando que se reemplaza:

Los comandos del día a día

• ›reword ( r ): conservar el commit pero reescribir su mensaje.
• ›squash ( s ): fusionar en el commit anterior conservando ambos mensajes.
• ›fixup ( f ): como squash, pero descartando el mensaje del commit fusionado — perfecto para un «wip» o una corrección de errata.
• ›edit ( e ): detenerse en el commit para modificar el código o dividirlo.
• ›drop ( d ): eliminar el commit por completo.

Reordenar se hace simplemente moviendo las líneas . Aquí el todo anterior limpio:

Al guardar, Git reproduce los commits en el nuevo orden. Si dos modificaciones tocan la misma línea, aparece un conflicto : se resuelve, luego git add y git rebase --continue . En cualquier momento, git rebase --abort devuelve la rama a su estado anterior.

El fixup automático

Para preparar una corrección destinada a un commit concreto, --fixup y luego --autosquash lo organizan todo por ti:

La regla de oro

Nunca rebasear un historial compartido. El rebase reescribe los commits: sus SHA cambian. Si la rama ya está en el repositorio remoto y los compañeros la han descargado, tu git push --force divergirá de su copia y provocará conflictos desagradables. Por tanto, se rebasea únicamente una rama local , aún no publicada — o una rama de la que se es el único propietario, con un git push --force-with-lease que rechaza sobreescribir trabajo inesperado.

Recuperarse tras un error

Un rebase que sale mal nunca es fatal: git reflog guarda un registro de cada posición de HEAD , incluso las «perdidas» por la reescritura.

Se recupera la rama exactamente tal como estaba antes del rebase. La documentación de referencia es el manual git-rebase .

El rebase interactivo reescribe la historia para hacerla narrable : un commit = una idea, un mensaje claro. Resérvalo para lo local, asegura tus pushs con --force-with-lease , y recuerda que el reflog es tu red de seguridad.