Cómo utilizar Git Rebase paso a paso y sin liarla

Si llevas un tiempo trabajando con Git en Visual Studio, seguramente habrás oído eso de “haz un rebase antes de abrir el PR” o “no hagas rebase sobre remoto” y quizá sigas con la mosca detrás de la oreja sin tener del todo claro qué demonios está pasando en el historial. Git rebase tiene fama de potente, pero también de peligroso, y ese respeto suele venir de no entender bien qué hace bajo el capó.

En esta guía vamos a desgranar con calma qué es rebase, cómo se diferencia de merge, en qué casos te interesa usar rebase y cuándo es mejor ni tocarlo, cómo funciona el rebase interactivo, qué peligros conlleva reescribir el historial y cómo recuperarte si algo sale mal. Todo explicado en castellano de España, con ejemplos prácticos y sin dar nada por supuesto.

¿Qué es Git rebase?

Git rebase es un comando que permite “mover” una serie de commits a una nueva base dentro del grafo de historial de Git. En lugar de fusionar dos ramas creando un commit de merge, lo que hace rebase es “reaplicar” uno a uno los commits de una rama encima de otro punto del historial, generando nuevos identificadores de commit y dejando una línea temporal más limpia y lineal.

Imagina que tienes la rama master y a partir de un commit A creas una rama feature. En esa rama haces varios commits mientras en master también siguen avanzando. El rebase te permite decirle a Git: “coge mis commits de feature y reescríbelos como si los hubiera hecho justo encima de los últimos cambios de master”, de forma que el historial resulte más ordenado y sin commits de merge intermedios.

Esta operación implica que Git reescribe el historial de la rama que estás rebasando. No es una simple reorganización visual: se crean nuevos commits con nuevos hashes y los antiguos dejan de estar referenciados (aunque puedan seguir en el reflog durante un tiempo). Por eso se dice que rebase es tan poderoso como delicado.

Una forma de entenderlo es pensar que, mientras el merge conecta dos líneas de trabajo con un punto de unión, rebase “levanta” tu rama, copia sus commits y los pega sobre otra rama, como si siempre hubieran nacido allí. El resultado suele ser un historial más limpio, pero el precio es alterar la secuencia real de cómo se hicieron los cambios.

Rebase frente a merge: mismo objetivo, caminos distintos

El gran contexto en el que aparece rebase es cuando quieres integrar cambios de una rama en otra. Git te ofrece dos caminos: merge y rebase. Ambos terminan llevando el código al mismo sitio, pero el rastro que dejan en el historial es muy distinto.

Con git merge, tu rama actual incorpora los commits de otra rama y se genera un commit extra de fusión (salvo en casos de fast-forward). Eso mantiene intacta la historia real, pero si hay muchos merges, el gráfico de commits puede acabar pareciendo un plato de espaguetis. La ventaja es que no reescribes nada; simplemente añades.

Con git rebase, en lugar de crear un commit de merge, coges tus commits y los pones encima de otra rama, como si siempre hubieran estado allí. El resultado es una historia lineal donde se ve claramente “sobre qué” se construyó cada cambio. El reverso de la moneda es que se modifican los hashes de commit y, si esos commits ya estaban compartidos, puedes liar bastante el repositorio remoto y el de tus compañeros.

En equipos grandes es habitual combinar ambas estrategias: se usa rebase en ramas locales o antes de hacer un merge para limpiar el historial de una feature, y luego se integra en la rama principal con un merge (a veces sin fast-forward) para conservar un punto claro de integración.

La clave está en entender que ni merge ni rebase son “mejores” de forma absoluta; son herramientas distintas. Merge es más seguro y transparente; rebase es más elegante en el historial pero implica responsabilidad al reescribir commits.

Uso básico de Git rebase

El caso más típico de uso de rebase es cuando estás trabajando en una rama de funcionalidad y quieres traerte los últimos cambios de la rama principal (por ejemplo, master o develop) sin generar un commit de merge adicional. El flujo clásico sería algo así:

Estás en tu rama de trabajo, por ejemplo feature/login, y la rama master ha avanzado con nuevos commits desde que tú abriste la feature. Para ponerte al día de una forma lineal, harías:

git checkout feature/login
git fetch origin
git rebase origin/master

Con este comando, Git toma tus commits de feature/login y los vuelve a aplicar sobre el último commit de origin/master. Si no hay conflictos, terminas con un historial donde parece que tus cambios siempre se hicieron sobre la versión más actualizada de master.

También puedes hacer el rebase desde la rama de destino, por ejemplo:

git checkout feature/login
git rebase master

Esto asume que tu master local está actualizado. El resultado es el mismo: los commits de tu feature se reescriben por encima de master. En ambos casos, cada commit se vuelve a reproducir y, si hay conflictos, se te irán presentando uno por uno para que los resuelvas.

Otra variante muy habitual es rebasar una rama que se basaba originalmente en otra rama intermedia. Por ejemplo, tienes una rama feature que a su vez sirve de base a una rama branch. Si luego decides que branch debería colgar directamente de master en lugar de feature, puedes lanzar:

git checkout branch
git rebase master

El efecto es que branch “salta” desde la base antigua (feature) a la nueva base (master), manteniendo sus cambios pero apoyándose en otro punto del grafo de commits.

No reorganices el historial público

El principal aviso de seguridad con rebase es muy claro: no reescribas commits que ya se han compartido en un remoto y sobre los que otras personas pueden estar basando su trabajo. Esto es especialmente crítico en ramas como master, develop o cualquier rama colaborativa.

Cuando haces rebase a una rama y después haces git push -f o git push --force-with-lease, lo que estás diciendo es: “mi versión del historial sustituye a la que hay en el servidor”. Si alguien ha hecho commits en esa rama remota después de que tú la clonaras o la tiraras, esos commits pueden perderse o generar divergencias complicadas de arreglar.

Imagina el escenario: dos personas clonan un repositorio, cada una trabaja en su rama local basada en la misma rama remota, y una de ellas decide hacer rebase y forzar el push. La otra persona sigue trabajando con la historia antigua. En cuanto haga un pull o intente subir sus cambios, Git detectará que su base no coincide con la del remoto y empezarán los dolores de cabeza.

Por eso se suele recomendar usar rebase en ramas locales o en ramas de feature que todavía no se han compartido. Si necesitas limpiar commits antes de subirlos por primera vez, perfecto. Si la rama ya está en el remoto y hay más gente trabajando con ella, conviene pensárselo muy bien, coordinar con el equipo y, si se decide reescribir, avisar claramente.

La regla de oro que suele repetirse es: no rebase commits que no sean sólo tuyos. Si has sido la única persona que ha tocado esos commits y sabes lo que estás haciendo, adelante; si no, mejor tira de merge o abre otra rama para reorganizar.

Git rebase estándar frente a Git rebase interactivo

Cuando hablamos de rebase, en realidad estamos hablando de dos sabores: el rebase “normal” (no interactivo) y el rebase interactivo. El primero se limita a mover tus commits de una base a otra; el segundo te permite editar, reordenar, fusionar o eliminar commits durante el proceso.

El rebase estándar lo utilizas, por ejemplo, con git rebase master o git rebase origin/develop. Aquí Git aplica mecánicamente cada commit de tu rama sobre la nueva base y sólo se detiene si hay conflictos, donde intervienes para resolverlos y continúas con git rebase --continue.

El rebase interactivo se activa usando la opción -i, normalmente apuntando a un rango de commits desde la punta de la rama hacia atrás. Por ejemplo:

git rebase -i HEAD~5

Con esto le dices a Git que quieres “jugar” con los últimos cinco commits. Se abrirá tu editor de texto configurado para Git (por defecto suele ser vim o nano) con una lista de esos commits, cada uno precedido por la palabra pick. Ahí es donde puedes cambiar pick por otras instrucciones para reescribir el historial a tu gusto.

Este enfoque interactivo está pensado para pulir una serie de commits antes de compartirlos: unir cambios mínimos, corregir mensajes, dividir commits demasiado grandes o eliminar directamente confirmaciones que no deberían llegar al repositorio remoto.

Comandos de reorganización adicionales en rebase interactivo

En el archivo que abre git rebase -i verás algo parecido a:

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B

La idea es que puedes reemplazar pick por otros comandos para modificar cómo se tratará cada commit durante el rebase. Los más habituales son:

• pick (p): usa el commit tal cual.
• reword (r): aplica el commit pero detente para modificar el mensaje.
• edit (e): aplica el commit y detente para que puedas cambiar su contenido (por ejemplo, añadiendo o quitando archivos) mediante git commit --amend.
• squash (s): fusiona este commit con el anterior y permite editar el mensaje conjunto.
• fixup (f): igual que squash, pero descarta el mensaje de este commit y se queda con el del anterior.
• drop (d): elimina este commit del historial.

En el ejemplo de arriba podrías, por ejemplo, fusionar un commit que corrige otro anterior, mover uno más arriba, dividir uno grande y corregir un mensaje mal escrito. El archivo editado podría quedar así:

pick 1fc6c95 Patch A
squash fa39187 something to add to patch A
pick 7b36971 something to move before patch B
pick 6b2481b Patch B
fixup c619268 A fix for Patch B
edit dd1475d something I want to split
reword 4ca2acc i cant' typ goods

Al guardar y cerrar el editor, Git empezará a ejecutar estas órdenes en orden, deteniéndose cuando necesita tu intervención (por ejemplo, para confirmar el mensaje resultante de un squash, para que hagas cambios con edit o para que reescribas el mensaje en reword). Cada parada te muestra en el terminal qué debes hacer y te recuerda que, cuando hayas terminado, ejecutes git rebase --continue.

En un momento dado, Git te abrirá un archivo con un contenido similar a:

# This is a combination of two commits.
# The first commit's message is:
Patch A
# This is the 2nd commit message:
something to add to patch A

Ahí puedes dejar el mensaje combinado como está o editarlo para que represente mejor el cambio conjunto. De nuevo, guardas, cierras el editor y el rebase sigue avanzando hasta procesar todos los comandos.

Resumen del flujo de rebase interactivo

El proceso completo de un rebase interactivo suele seguir este patrón: primero seleccionas el rango de commits (por ejemplo HEAD~7), Git abre el archivo con la lista de commits y tú editas los comandos y el orden de las líneas para que coincidan con la historia que quieres conseguir. Después de guardar, Git va recorriendo cada instrucción, se detiene donde hace falta y, cuando llegas al final sin errores, tu rama tiene un historial totalmente remodelado.

Cada vez que se detiene, ya sea por un edit o por un conflicto de merge, puedes modificar archivos, usar git add, hacer un git commit --amend si procede y, cuando estés satisfecho con el estado, volver a git rebase --continue. Si cometes un error grave o ves que te has metido en un jardín, siempre puedes abortar con git rebase --abort para regresar al estado anterior a iniciar el rebase.

El resultado típico de usar rebase interactivo con cabeza es una serie de commits más lógica y legible: menos ruido, menos “fix typo”, menos commits repetitivos y mensajes más claros. Esto facilita mucho revisar el historial, entender qué se cambió y por qué, y hacer bisect o depuraciones futuras.

Opciones de configuración útiles para rebase

Git tiene varias opciones de configuración que afectan al comportamiento de rebase y que pueden hacerte la vida más fácil si lo utilizas habitualmente. Una de las más conocidas es la que permite que git pull use rebase en lugar de merge por defecto:

git config --global pull.rebase true

Con esto, cada vez que hagas git pull, Git intentará rebasar tus cambios locales sobre los nuevos commits del remoto en vez de crear un commit de merge. Es una forma cómoda de mantener un historial local lineal sin tener que recordar escribir siempre git pull --rebase.

También puedes ajustar el editor para el modo interactivo, configurar alias para comandos largos de rebase, o activar opciones como autostash en ciertos flujos, aunque conviene usarlas con cuidado para no perder de vista qué está haciendo Git con tus cambios sin commitear.

Aplicación de reorganización avanzada

Una vez dominas el rebase básico e interactivo, puedes empezar a usarlo en escenarios más avanzados, como cuando tienes varias ramas puntuales colgando unas de otras y quieres reacomodar su base sin ensuciar master. Por ejemplo, podrías tener una rama client y otra server que dependen entre sí y, tras unos cambios, te interesa que ambas se apoyen sobre una master que ya incorpora ciertas refactorizaciones.

En una situación así, podrías primero rebasar client sobre master, avanzar master con un fast-forward y después rebasar server sobre la nueva master. Con este tipo de maniobras consigues que el historial muestre claramente qué cambios pertenecen a cada rama y en qué orden lógico se aplicaron, sin una cadena de merges cruzados.

También es posible “reorganizar una reorganización”: si alguien rebasó una rama y tú después necesitas rebasar tu trabajo encima de ese historial ya reescrito, Git te permite hacerlo, aunque aquí la probabilidad de conflictos y confusión aumenta. En entornos colaborativos conviene planificar muy bien estas operaciones y, si hace falta, apoyarse en diagramas del historial para no perderse.

Comprensión de los peligros de la reorganización

El mayor peligro de rebase radica en su propia virtud: reescribe la historia. Eso está genial para dejar las cosas bonitas, pero es un arma de doble filo si los commits ya han sido publicados o si varias personas se apoyan en ellos para su trabajo diario.

Imagina que clonas un repositorio y empiezas a trabajar en tu rama local mientras otros compañeros siguen empujando cambios a la rama principal. Si uno de ellos decide hacer un rebase sobre esa rama principal y fuerza el push, los commits que tú tenías como base pueden desaparecer del remoto o cambiar de hash. Desde tu punto de vista local, tu historia dice una cosa; desde el remoto, dice otra.

Cuando intentes hacer un pull o un push, Git se verá obligado a reconciliar dos historias incompatibles y puede terminar creando merges extraños o rechazando el push. A menudo acabarás con confirmaciones duplicadas, con el mismo contenido pero distintos hashes, y un historial aún más enrevesado de lo que tenías al principio.

Otro riesgo es el de perder información por un push forzado imprudente. Si mientras tú estás reescribiendo el historial otra persona ha hecho commits legítimos en el remoto, un git push --force sin más puede sobreescribir esos cambios y hacer que desaparezcan de la vista. Recuperarlos puede requerir mucho tiempo y conocimiento de reflogs, siempre que no haya pasado demasiado.

Por todo esto, rebase se considera una herramienta “sorprendente” pero que debe usarse con criterio. A nivel individual te permite tener un historial impecable; a nivel de equipo, mal usado, puede romper la coordinación de la gente y generar conflictos difíciles de resolver.

Recuperación de una reorganización de nivel superior

Si un rebase se te va de las manos, lo primero es no entrar en pánico. Git conserva un registro llamado reflog que guarda las posiciones anteriores de las referencias (como HEAD) durante un tiempo. Eso significa que, aunque hayas reescrito commits, es posible que todavía puedas acceder a ellos y restaurar el estado anterior.

En medio de un rebase que está saliendo mal, lo más rápido suele ser hacer:

git rebase --abort

Con esto Git intentará devolverte exactamente al punto desde el que iniciaste la operación de rebase, como si jamás lo hubieras empezado. Es ideal cuando, por ejemplo, te ves metido en una cadena interminable de conflictos y decides que no compensa seguir por ese camino.

Si el problema es que ya has completado el rebase y has hecho incluso un push forzado, la cosa se complica. En local puedes usar git reflog para localizar el hash del commit donde estabas antes del rebase y, una vez lo tengas, hacer un git reset --hard a ese punto. Sin embargo, si has sobrescrito el remoto y otros clones ya se han actualizado, volver atrás implica coordinación de todo el equipo y, en algunos casos, aceptar que parte del trabajo se ha “perdido” en el sentido de que no forma parte ya de la historia oficial.

Cuando el error de rebase afecta a varias personas, la solución práctica suele pasar por acordar un nuevo punto de partida en una rama (por ejemplo, crear una nueva a partir de un commit sano) y ir rescatando cambios desde las ramas afectadas, ya sea con cherry-pick o aplicando parches. Es una faena, pero suele ser preferible a intentar “deshacer mágicamente” una historia compartida que ya ha cambiado varias veces.

Merge conflicts en rebase

Los conflictos de merge durante un rebase funcionan de forma parecida a los de un merge normal, con la diferencia de que aparecen commit a commit. Cada vez que Git intenta aplicar un commit y detecta que el mismo fragmento de un archivo ha cambiado de forma incompatible en la base, te dejará el conflicto marcado en los ficheros.

Dentro del archivo verás delimitadores como:

<<<<<<< HEAD
contenido de tu rama actual
=======
contenido de la rama rebasada
>>>>>>> updated_address

Entre <<<<<<< HEAD y ======= tienes el contenido de una de las versiones, y entre ======= y >>>>>>> la otra. Tu tarea es editar el archivo, dejar sólo la combinación que tenga sentido para el proyecto y eliminar esas líneas de marcadores.

Una vez resuelto el contenido en todos los archivos afectados, usas git add <archivo> para marcar los conflictos como solucionados. Después ejecutas git rebase --continue para que Git siga con el siguiente commit de la serie. Si te encuentras un conflicto que no merece la pena resolver para ese commit en concreto, también tienes opciones como git rebase --skip para saltártelo, aunque esto implica omitir por completo ese commit del historial resultante.

Porque el rebase aplica commits uno detrás de otro, en ramas con muchos cambios y diferencias grandes con la base, puede ser algo tedioso: cada confirmación que toque el mismo trozo de código conflictivo te obligará a resolverlo. En esos casos, puede compensar más un merge normal o reorganizar primero los cambios para reducir la superficie de conflicto.

Git rebase, push –force y push –force-with-lease

Siempre que reescribes el historial de una rama y esa rama está conectada con un remoto, vas a chocar con el control de seguridad que hace Git: si el remoto tiene una historia distinta, un simple git push será rechazado. Para sustituir esa historia necesitas un push forzado.

Hay dos variantes habituales: git push --force y git push --force-with-lease. La primera sobrescribe sin hacer preguntas, mientras que la segunda añade una especie de “seguro” para evitar pisar commits ajenos. Con --force-with-lease, Git comprueba que el remoto sigue apuntando al commit que tú crees; si alguien ha cambiado la rama en el servidor mientras tú reescribías tu historia local, el push será rechazado.

Piensa en el caso en que tienes en el remoto una secuencia de commits y decides que uno (por ejemplo, c2) es incorrecto. Localmente lo reescribes, generas nuevos commits (c3, c4) y quieres que esos sean la nueva realidad. Si nadie más ha tocado la rama, un push con –force-with-lease actualizará el remoto sin problemas. Pero si alguien ha metido, por ejemplo, un commit c5 mientras tú preparabas tus cambios, ese flag evitará que borres su trabajo sin darte cuenta.

En resumen, si ya has asumido que necesitas forzar el push tras un rebase, lo habitual es usar git push --force-with-lease salvo que tengas un motivo muy concreto para querer sobrescribirlo absolutamente todo con --force. Incluso así, conviene comunicarlo con el equipo y coordinar el momento para minimizar conflictos.

Rebase, contextos de ramas y flujo de trabajo

Otra manera interesante de entender rebase es pensar en las ramas como contextos de trabajo que comparten una parte del historial pero luego avanzan por caminos separados. Por ejemplo, si sigues un flujo tipo git-flow, puedes tener una rama develop desde la que se crean ramas de funcionalidad (A1, A2, etc.).

Cuando estás en el contexto A1, todo lo que hagas ahí no afecta a develop hasta que haces un merge o decides rebasar. Es como si tuvieras dos líneas temporales paralelas que comparten un origen pero van acumulando cambios distintos. Con un merge, unes esas líneas y Git registra un commit donde convergen; con un rebase, reorganizas la línea de A1 para que parezca que siempre estuvo unos pasos más adelante de develop.

Si durante el desarrollo Pepe trabaja sobre develop y Nacho sobre A1, llegará un momento en que develop tenga commits nuevos y A1 también. Si Nacho quiere evitar un commit de merge al integrar A1 en develop, puede hacer:

git checkout A1
git rebase develop

Git traerá los commits de develop “debajo” de los de A1, reescribiendo la historia de A1 para que sus cambios queden encima de la última versión de develop. De cara al historial, pareciera que Nacho siempre se basó en el estado más actualizado de develop, aunque en realidad no haya sido así en tiempo real.

Este tipo de flujo es muy cómodo cuando trabajas tú solo o cuando la rama A1 todavía no ha sido compartida. El problema aparece cuando A1 ya está en el remoto y otros compañeros la han tirado. Si Nacho hace ese rebase de A1 sobre develop y luego fuerza el push, rompe el vínculo entre la versión remota y la versión local que tienen los demás, obligándoles a sincronizarse con una historia que ya no se parece a la que tenían.

Rebase y conflictos derivados en trabajo en equipo

En un escenario colaborativo, como el que acabamos de describir, la interacción entre rebase y los repositorios locales de cada persona puede ser delicada. Cuando Nacho hace rebase de A1, resuelve conflictos localmente y, satisfecho con el resultado, hace un git push --force-with-lease. El remoto ahora refleja la nueva historia reescrita.

Mientras tanto, Pepe sigue con su copia local de A1, que todavía está en la versión anterior al rebase. Si Pepe hace un pull o intenta subir cambios, Git detectará que su historial diverge de lo que hay en el remoto. En el mejor de los casos, tendrá que resetear su rama local al nuevo HEAD remoto y re-aplicar sus cambios; en el peor, puede perder trabajo si no tiene cuidado y hace un reset duro sin haber guardado nada.

Por eso, cuando se hace rebase en una rama compartida, es importante avisar claramente al resto del equipo para que actualicen su local de forma explícita, por ejemplo usando:

git fetch origin
git checkout A1
git reset --hard origin/A1

Este tipo de operaciones deben ser excepciones, no la norma. Para el día a día, suele ser mejor limitar el rebase a ramas de feature personales y dejar las ramas compartidas (develop, master) con un historial basado en merges, que no rompen los clones locales de nadie.

En cuanto a los conflictos que surgen durante un rebase, la dinámica siempre es la misma: Git te presenta cada conflicto commit a commit, tú editas los archivos implicados, marcas los cambios como resueltos con git add y continúas con git rebase --continue. Si, por la razón que sea, la situación se descontrola, puedes abortar y replantear la estrategia.

Rebase interactivo: diversión y limpieza para todos

Aunque en muchos tutoriales se pasa de puntillas, el modo interactivo de rebase es uno de los grandes aliados para dejar un historial limpio, coherente y fácil de revisar. Con git rebase -i puedes, en una sola sesión, fusionar commits pequeños, corregir mensajes, mover confirmaciones hacia arriba o abajo en el tiempo, dividir un commit grande en varios más lógicos o directamente eliminar cambios que no tienen sentido.

Por ejemplo, si quieres refinar los últimos siete commits, lanzas:

git rebase --interactive HEAD~7

Se abrirá tu editor con la lista de esos siete commits. A partir de ahí puedes decidir que un determinado commit de arreglos menores se fusione con el commit original de la funcionalidad (usando squash o fixup), que otro commit se mueva antes que “Patch B”, que un tercer commit se divida en dos con edit, o que un mensaje con erratas se corrija con reword.

La gracia es que todo este trabajo se hace antes de compartir los cambios con el resto del mundo, de forma que lo que llega al remoto ya es una historia razonablemente limpia. Esto no sólo queda más bonito: facilita que otro desarrollador revise tus commits, entienda de un vistazo qué aporta cada uno y, si hace falta, use herramientas como git bisect para encontrar el punto exacto donde se introdujo un bug.

Eso sí, conviene recordar la regla de siempre: todo lo que hagas con rebase interactivo reescribe hashes de commits. Úsalo con mucha tranquilidad en ramas que sólo existen en tu máquina, y con mucha cautela en cualquier rama que ya viaja a un remoto.

En definitiva, rebase (y, en especial, su modo interactivo) es una especie de “editor de historia” de Git. Bien utilizado, te permite mantener un repositorio con un historial muy legible y profesional; mal utilizado, puede causar confusiones y dolores de cabeza, sobre todo cuando se mezclan ramas ya compartidas y push forzados sin coordinación.

Dominar este comando lleva un tiempo, pero una vez entiendes qué hace exactamente con tus commits, se convierte en una herramienta clave para trabajar con ramas, mantener historiales limpios y colaborar de forma fluida en proyectos de cualquier tamaño.