• Básicos Git (I): Cherry pick
• Básicos Git (II): Rebase
• Básicos Git (III): Revert
• Básicos Git (IV): Reset
• Básicos Git (V): Amend
• Básicos Git (VI): Stash

Existe otra forma de hacer una fusión de ramas y es con un comando rebase. Rebase lo que hace es insertar una rama dentro de otra en el mismo punto donde se creo de tal forma que parezca una sola rama.

Situación inicial

Para poder entenderlo bien vamos a manejar dos ramas, master y develop, creamos dos commits en develop y otros dos en master, el orden no es importante (Figura 1).

En este punto master y develop divergen y tienen commits diferentes, vamos a aplicar un rebase para crear una sola rama con todos los cambios.

Aplicando rebase

Para tener una sola rama rama vamos a hacer un rebase, nos posicionamos en la rama master con los parámetros que se ven en la imagen y pulsamos rebase.

Conflictos

Esto provocará varios conflictos, el rebase irá aplicando primero cada cambio de master a develop, los conflictos que se aplicarán a develop son:

1. El primer commit de develop (que sería el existente) con el primer commit de master (Commit C1).
2. El resultado del commit anterior con el segundo commit de master (Commit C2).
3. Así sería sucesivamente si hubiera más commits.

Estos nuevos commits tendrán como comentarios los correspondientes a su commit de master.

Ahora para terminar el rebase solo queda aplicar estos cambios de la rama develop en la rama master provocando un último conflicto (Commit R), en este caso si que habrá que indicar un comentario.

Resultado

En la imagen anterior si nos fijamos en la rama master vemos que están todos los commits de develop insertados en la rama master (recuadro rojo) justo en el punto que se creo la rama develop, por lo que en master queda un arbol límpio con todos los commits.

Este sistema se suele utilizar más para actualizar ramas locales que para actualizar la rama master ya que se está alterando el historial de una rama (master en este caso).

Esto también provoca que se altere el cronograma por lo que podemos ver commits más recientes que aparecen más tarde en el historial, ya que prima el orden de creación más que la fecha de los mismos.

Este sistema también puede crear un problema para el resto de desarrolladores que hayan creado otras ramas de master a posteriori lo que genera conflictos a veces complicados de resolver.

Generalmente no se recomienda hacer un rebase sobre ramas remotas por el peligro que conlleva para otros desarrolladores, sin embargo en ramas locales suele haber más disparidad de criterio.