Rebase

Ya hemos visto cómo fusionar cambios de una rama en otra. Para ello hemos usado el comando git merge.

Sin embargo existe otro comando que nos permite conseguir el mismo resultado a base dereordenarel historial de commits. Este comando es git rebase.

Rebasees, seguramente, uno de los comandos más complejos de Git (y más peligroso). Por ello, vamos a dedicarle un capítulo entero para explicarlo y que lo entiendas bien.

¿Qué es el rebase?

El rebase es unaoperación que nos permite reescribir el historial de commitsde una rama.

Esto significa que podemosañadir, mover, ordenar o eliminar commits directamente de un historial de commits. Es como tener el superpoder de viajar en el tiempo y cambiar el pasado, presente o futuro de nuestra rama.

¿Y si ya tenemos git merge? ¿Para qué necesitamos git rebase? La principal razón es la demantener el historial de commits de tu ramalo más limpio, ordenado y lineal posible.

¿Cómo usar git rebase?

Para usar git rebasedebemos seguir los siguientes pasos:

1. Seleccionar la rama a la que queremos añadir commits: para ello debemos situarnos en la rama a la que queremos añadir commits. Por ejemplo, si queremos añadir commits a la rama main, debemos situarnos en ella:

$ git switch main

2. Ejecutar git rebase : una vez situados en la rama a la que queremos añadir commits, ejecutamos git rebasey le pasamos como parámetro la rama de la que queremos añadir commits:

$ git rebase feature

3. Resolver los conflictos: si hay conflictos, en este paso deberemos resolverlos.

Resolviendo conflictos con git rebase

Al hacer un git rebasees posible que tengas conflictos. Como estamos reescribiendo el historial de commits, es posible que dos commits diferentes modifiquen la misma línea de un mismo archivo y Git no sabe qué cambio aplicar.

Git te lo indicará con el siguiente mensaje impreso en la terminal:

error: could not apply af42187... something to add to patch A

Cuando hayas resuelto este problema, ejecuta “git rebase –continue”. Si prefieres saltar este parche, ejecuta “git rebase –skip” en su lugar.

Para volver a la rama original y detener el rebase, ejecuta “git rebase –abort”. Could not apply fa39187f3c3dfd2ab5faa38ac01cf3de7ce2e841… Change fake file Aquí, Git te está indicando qué commit está causando el conflicto (fa39187).

Tienes tres opciones:

1. Puedes ejecutar git rebase —abortpara deshacer completamente el rebase. Git volverá al estado de tu rama tal como era antes de que se llamara a git rebasey podrás empezar de cero. 2. Con git rebase —skippuedes saltar completamente el commit. Esto significa que ninguno de los cambios introducidos por el commit problemático se incluirá. Ojo porque, si haces esto, estás perdiendo cambios. 3. Arreglar el conflicto. Básicamente, modificar los archivos para que el conflicto deje de existir. Una vez hecho esto, debemos ejecutar git rebase —continue para que Git continúe procesando el resto del rebase.

Rebase interactivo

El rebase interactivo es una herramienta que nos permite reescribir el historial de commits de una rama de forma interactiva.

Para ello debemos añadir el parámetro -i o--interactive cuando usemos el
comando:

$ git rebase --interactive

Esto creará un archivo en el editor de texto que tengas configurado por defecto. En este archivo verás una lista de commits de la rama actual, ordenados cronológicamente, que podrás editar:

pick 2ee9f59 Fix linter errors
pick c29f6c8 Remove not needed countdown
pick ee4b85c add official color
pick 82ff110 add iframe twitch
pick 1a3e40d iframe centered
pick ca745cf change script
pick 0e3d6f8 fix eslint errors
pick bde26c5 fix: fix lint errors
pick 490df4c fix: iframe in mobile
pick cabb633 feat: show twitch iframe only if tu-usuario is live on twitch
pick 96ce7b6 feat: add animated twitch iframe border

# Rebase 8d7813d..8686bad onto 8d7813d (11 commands)

En este archivo, cada línea representa un commit. En la primera columna, verás un comando que indica qué hacer con el commit. Los comandos más comunes son:

• p, pick (commit): usa el commit tal como está

• r, reword (commit): usa el commit pero cambia el mensaje

• e, edit (commit): usa el commit pero permite editarlo

• s, squash (commit): usa el commit pero lo fusiona con el anterior

• f, fixup (commit): usa el commit, lo fusiona con el anterior y descarta el mensaje

• x, exec (command): ejecuta el comando en elshell - b, break: para aquí para continuar el rebase más tarde con ‘git rebase –continue’ - d, drop (commit): borra el commit - l, label (label): etiqueta el HEAD actual con un nombre - t, reset (label): resetea la etiqueta HEAD a otro nombre - m, merge [-C (commit) | -c (commit)] (label) [# (oneline)]: crea un commit de mergeusando el mensaje del commit original (o eloneline, si no se especificó ningún commit original). Usa -c (commit) para reescribir el mensaje del commit.

Por defecto el comando espicky, por tanto, se usa el commit tal como está. Si quieres cambiar el comando de un commit, simplemente cambia la palabra por el comando que quieres usar (puedes usar la letra o el comando completo).

Cambiar el mensaje de un commit

Si quieres cambiar el mensaje del commitc29f6c8, simplemente cambia la palabra pickporreword:

pick 2ee9f59 Fix linter errors
reword c29f6c8 Remove not needed countdown
...

Guarda el archivo y Git te abrirá un nuevo fichero para que indiques el nuevo mensaje del commit.

Reordenando commits

También puedes cambiar el orden de los commits. Por ejemplo, si quieres que el commitee4b85cse haga antes que el commit82ff110, simplemente cambia el orden de las líneas:

pick 2ee9f59 Fix linter errors
pick c29f6c8 Remove not needed countdown
pick 82ff110 add iframe twitch # <-- arriba
pick ee4b85c add official color # <-- abajo

Guarda el archivo y Git reordenará los commits.

Borrar commits

Si quieres borrar un commit, simplemente cambia el comandopickpordrop:

pick 2ee9f59 Fix linter errors
pick c29f6c8 Remove not needed countdown
drop ee4b85c add official color # <-- este commit se borrará
pick 82ff110 add iframe twitch

Guarda el archivo y Git borrará el commit.

Fusionar commits

Si quieres fusionar dos commits, simplemente cambia el comandopickporsquash:

pick 2ee9f59 Fix linter errors
pick c29f6c8 Remove not needed countdown
squash ee4b85c add official color # <-- este commit se fusionará con el\
anterior
squash 82ff110 add iframe twitch # <-- este commit se fusionará con el \
anterior

Te abrirá un nuevo archivo para que indiques el mensaje del commit resultante de la fusión.

# This is a combination of 3 commits.

add iframe twitch

# This is the commit message #2:
add official color

# This is the commit message #3:
Remove not needed countdown

# Please enter the commit message for your changes. Lines starting

Guarda el archivo y Git fusionará los commits con el nombre de commit que hayas indicado.

Separar un commit en dos o más

Si quieres separar un commit en dos o más, simplemente cambia el comandopick
poredit:

pick 2ee9f59 Fix linter errors
pick c29f6c8 Remove not needed countdown
edit ee4b85c add official color # <-- este commit se podrá editar
pick 82ff110 add iframe twitch

Ahora, podemos hacer un git resetpara deshacer los cambios del commitee4b85cy hacer un nuevo commit con los cambios que queramos usando git addy git commit:

$ git reset HEAD^
$ git add file1
$ git commit -m 'Update file1 formatting'
$ git add file2
$ git commit -m 'Add file2 feature'
$ git rebase --continue # continuamos con el rebase

Te recomiendo que antes de aplicar el rebase, pruebes a jugar con todos estos comandos en un repositorio de prueba para que veas cómo funcionan y qué problemas puedes encontrarte. Jugar con el historial siempre es peligroso, ya que el orden de los commits es muy importante para Git.

Abortar un rebase

Si por cualquier motivo quieres abortar un rebase, simplemente ejecuta git rebase —abort:

$ git rebase --abort

Esto te devolverá el historial a su estado original, eliminará la carpeta .git/rebase-applyy te dejará en el commit en el que estabas antes de empezar el rebase.

No uses git rebase para esto

A veces tenemos la tentación de usar rebase paraarreglarel historial. ¿Se te ha escapado un token de una API? Vamos a reescribir el historial para borrarlo. ¿Te has equivocado en un commit y ya has hecho push? Vamos a reescribir el historial para arreglarlo…

Pues no, no lo hagas. En el caso del token de una API, lo mejor que puedes hacer, es generar o conseguir un nuevo token. Una vez que un token ha llegado a un repositorio remoto, especialmente si es público en GitHub, puede ser demasiado tarde ya que existenbotsque lo detectan y lo reportan.

En el caso de un commit equivocado, depende un poco de la situación. Si ya has hechopushy es una rama en la que estás trabajando, nadie más trabaja en ella y, sobretodo, no es la rama principal, entonces puedes hacer rebase. En cualquier otro caso, lo mejor es que uses git revert.

Vamos, no uses git rebase simplemente porque quieres dejar el historial bonito.

Los peligros del rebase

Reescribir la historia suena peligroso. Y lo es. Asegúrate de entender qué estás haciendo antes de usar el comando git rebase.

1. Perdida de trabajo: uno de los mayores peligros de usar git rebasees la posibilidad de perder trabajo. Al reescribir la historia del repositorio, es posible elimines commits que todavía son necesarios en tu rama actual. Si no tienes cuidado, es posible que acabes perdiendo trabajo importante sin darte cuenta. 2. Conflictossilenciosos: otro peligro de usar git rebase es la posibilidad de crear conflictos al integrar commits. Al reescribir la historia del repositorio, es posible que git rebasecree conflictos con commits que ya hayan sido integrados pero que no recibas avisos de que esto ha ocurrido. 3. Una historia artificial: al reescribir la historia de una repositorio, es posible que se pierda información sobre el desarrollo de la rama. ¿De dónde salieron los commits que tiene la rama? ¿En qué orden fueron escritos? Sí, la historia queda más lineal y limpia pero es artificial, ya que no refleja exactamente el trabajo del equipo.