Git rebase: cómo poner los cambios al principio de una rama

Git rebase integra los cambios de una rama en otra. Este comando Git ofrece más po­si­bi­li­da­des que Git Merge, pero debe uti­li­zar­se con pre­cau­ción.

Una ca­ra­c­te­rí­s­ti­ca especial y decisiva del trabajo con Git es la po­si­bi­li­dad de trabajar en equipo o en solitario y en paralelo en di­fe­re­n­tes partes de un proyecto, rea­li­za­n­do cambios, so­lu­cio­na­n­do problemas y volviendo a poner a di­s­po­si­ción los co­no­ci­mie­n­tos ad­qui­ri­dos para el conjunto. Esto funciona, por un lado, mediante el uso de re­po­si­to­rios locales y, por otro, (un paso más abajo) mediante el uso de ramas. En ellas, se puede trabajar de forma autónoma en un cambio y no ejercer ini­cia­l­me­n­te ninguna in­flue­n­cia en el resto del proyecto. Sin embargo, si luego quieres integrar los cambios de una rama en otra, el sistema de control de versiones ofrece dos opciones.

Tanto git merge como git rebase son adecuados para fusionar, pero también difieren si­g­ni­fi­ca­ti­va­me­n­te entre sí. Git rebase se considera la solución más so­fi­s­ti­ca­da. Con este comando de Git, una serie de commits se tra­n­s­fie­ren a un nuevo commit de base. Esto cambia la base de ese commit y se mueve una rama entera a la parte superior de otra rama en el proceso. Para ello, git rebase reescribe el historial del proyecto a medida que se crean nuevos commits para los commits de la rama original. Con git rebase, se distingue entre un enfoque manual y uno in­ter­ac­ti­vo.

Para entender exac­ta­me­n­te cómo funciona git rebase, primero vale la pena echar un vistazo a su sintaxis. Esto se explica con relativa rapidez. Usando git checkout un comando que también puedes encontrar en la práctica hoja Git Cheat de­s­ca­r­ga­ble en PDF abrimos la “nueva” rama del siguiente ejemplo, que queremos integrar en la “master” con git rebase. Esto funciona de forma bastante sencilla a través del comando co­rre­s­po­n­die­n­te, donde solo tenemos que es­pe­ci­fi­car la rama de destino. Se ve así:

Así, la rama “nueva” se coloca ahora en la parte superior de la rama “master” y se reescribe el historial del proyecto.

El ejemplo mostrado arriba es la versión estándar de git rebase. El comando se ejecuta au­to­má­ti­ca­me­n­te en la rama ac­tua­l­me­n­te se­le­c­cio­na­da y se aplica a la rama HEAD (en este caso “master”). Todos los commits se mueven y se colocan en la parte superior de la nueva rama. La versión in­ter­ac­ti­va de git rebase te ofrece otras opciones útiles. Puedes se­le­c­cio­nar, modificar, mover o eliminar cada uno de los commits. Esto te da la opo­r­tu­ni­dad de ordenar el historial según desees y op­ti­mi­zar­lo. El comando se parece bastante a la versión estándar, pero contiene el pequeño añadido “-i”:

Si ejecutas este comando, se abrirá au­to­má­ti­ca­me­n­te un editor en el que recibes una lista de todos los commits y puedes ada­p­tar­los según tus propias ideas.

Para los usuarios avanzados, git rebase ofrece otras opciones útiles. Estas son las más im­po­r­ta­n­tes:

En muchos aspectos, git rebase es similar a git merge. Ambos comandos integran los cambios de una rama en otra. Git merge deja las ramas exi­s­te­n­tes co­m­ple­ta­me­n­te intactas. Esto es ventajoso porque se conserva todo el historial. Sin embargo, también crea muchos commits de fusión in­ne­ce­sa­rios. Git rebase es la solución lineal que ofrece muchas opciones de pe­r­so­na­li­za­ción debido a su enfoque in­ter­ac­ti­vo, pero se considera una opción para usuarios avanzados.

Git rebase ofrece una gran ventaja y una posible de­s­ve­n­ta­ja. El efecto positivo de este comando es que deja un historial limpio y claro en el proyecto. Con git rebase, el historial es co­m­ple­ta­me­n­te lineal y no contiene ninguna bi­fu­r­ca­ción desde el principio hasta el final. Esto facilita la na­ve­ga­ción y hace que todo el proyecto sea más ágil. Sin embargo, esta reducción también significa que no tiene que haber tra­za­bi­li­dad ne­ce­sa­ria­me­n­te. Los commits pueden perderse, lo que puede llevar a co­n­fli­c­tos de fusión, es­pe­cia­l­me­n­te cuando se trabaja en un equipo más grande. Por lo tanto, git rebase es un comando muy eficaz y útil, pero debe uti­li­zar­se con pre­cau­ción.

Sobre todo, esto significa que no debes usar git rebase en ramas públicas. De lo contrario, fu­sio­na­rías la rama principal en tu re­po­si­to­rio local, pero los miembros de tu equipo seguirían tra­ba­ja­n­do en una versión co­m­ple­ta­me­n­te diferente. Por lo tanto, sería muy difícil, incluso imposible, volver a si­n­cro­ni­zar el proyecto.