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 posibilidades que Git Merge, pero debe utilizarse con precaución.

Una característica especial y decisiva del trabajo con Git es la posibilidad de trabajar en equipo o en solitario y en paralelo en diferentes partes de un proyecto, realizando cambios, solucionando problemas y volviendo a poner a disposición los conocimientos adquiridos para el conjunto. Esto funciona, por un lado, mediante el uso de repositorios 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 inicialmente ninguna influencia 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 significativamente entre sí. Git rebase se considera la solución más sofisticada. Con este comando de Git, una serie de commits se transfieren 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 interactivo.

Para entender exactamente 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 descargable 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 correspondiente, donde solo tenemos que especificar 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 automáticamente en la rama actualmente seleccionada 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 interactiva de git rebase te ofrece otras opciones útiles. Puedes seleccionar, modificar, mover o eliminar cada uno de los commits. Esto te da la oportunidad de ordenar el historial según desees y optimizarlo. 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á automáticamente un editor en el que recibes una lista de todos los commits y puedes adaptarlos según tus propias ideas.

Para los usuarios avanzados, git rebase ofrece otras opciones útiles. Estas son las más importantes:

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 existentes completamente intactas. Esto es ventajoso porque se conserva todo el historial. Sin embargo, también crea muchos commits de fusión innecesarios. Git rebase es la solución lineal que ofrece muchas opciones de personalización debido a su enfoque interactivo, pero se considera una opción para usuarios avanzados.

Git rebase ofrece una gran ventaja y una posible desventaja. El efecto positivo de este comando es que deja un historial limpio y claro en el proyecto. Con git rebase, el historial es completamente lineal y no contiene ninguna bifurcación desde el principio hasta el final. Esto facilita la navegación y hace que todo el proyecto sea más ágil. Sin embargo, esta reducción también significa que no tiene que haber trazabilidad necesariamente. Los commits pueden perderse, lo que puede llevar a conflictos de fusión, especialmente cuando se trabaja en un equipo más grande. Por lo tanto, git rebase es un comando muy eficaz y útil, pero debe utilizarse con precaución.

Sobre todo, esto significa que no debes usar git rebase en ramas públicas. De lo contrario, fusionarías la rama principal en tu repositorio local, pero los miembros de tu equipo seguirían trabajando en una versión completamente diferente. Por lo tanto, sería muy difícil, incluso imposible, volver a sincronizar el proyecto.