El comando git rebase es una operación avanzada que permite reescribir el historial del repositorio, cambiando la “base” de tu rama actual para mover sus commits y aplicarlos de forma secuencial en la punta de otra rama.
Hasta ahora, la única forma que hemos visto para mezclar código es git merge. Merge es una operación conservadora y segura porque respeta la historia tal y como ocurrió: si dos ramas avanzaron en paralelo, Git las une creando un “merge commit”.
Pero a veces la historia es… fea. Ramas que salen y entran, commits con mensajes de “typo”, “fix”, “wip”, y un grafo que parece un plato de espaguetis y cosas que quieres olvidar…
Para solucionar esto, Git nos ofrece una herramienta para reescribir la historia: git rebase.
Es una de las utilidades más potentes y elegantes de Git, pero también es la más peligrosa. Hoy vamos a aprender a usarla sin destruir el trabajo tu trabajo o el de tus compañeros.
¿Qué es “Re-basar”?
Para entenderlo, miremos el nombre. Re-base, es decir, “Cambiar la base”.
Vamos a verlo con un ejemplo.
Creas una rama feature a partir de main (en el commit A).
Haces dos commits en tu rama (X e Y).
Mientras tanto, alguien actualiza main con nuevos commits (B).
Tu rama feature nace del commit A. Su base es A.
Si hacemos un Merge tradicional, Git crea un commit de fusión que une Y y B. La historia se bifurca y se une.
Pero si hacemos un Rebase, le decimos a Git: “Quita mis commits X e Y de aquí, y pégalos como si hubieran nacido a partir del commit B”.
Estamos cambiando el punto de origen de nuestra rama (y por eso se llama rebase).
Rebase vs Merge
¿Por qué querríamos complicarnos la vida moviendo commits?
| Característica | git merge | git rebase |
|---|---|---|
| Enfoque | Preservar la historia exactamente como ocurrió | Conseguir una historia lineal y limpia |
| Resultado | Grafo con bifurcaciones y uniones (Merge Commit) | Una única línea recta, simulando trabajo secuencial |
| Ventaja | Operación segura y no destructiva. | Historial (git log) impecable, sin commits de integración inútiles |
| Desventaja | Puede genera un historial ruidoso (“efecto Guitar Hero”) | Reescribe la historia. Puede romper el código del equipo |
Cómo hacer un Rebase
La sintaxis es sencilla. Si estás en tu rama feature y quieres actualizarte con lo último de main:
git switch feature
git rebase main
Lo que ocurre internamente:
Git “levanta” tus commits (X, Y) y los guarda temporalmente.
Actualiza tu rama feature para que apunte a lo mismo que main (commit B).
Vuelve a aplicar (“Replay”) tus commits uno a uno sobre la nueva base.
Durante este proceso pueden surgir conflictos. Si ocurre, Git se detendrá en cada commit conflictivo, te pedirá que lo resuelvas y luego continuarás con git rebase --continue.
Se viene disclaimer
Como el Rebase vuelve a aplicar los commits, genera nuevos Hashes. Para Git, el commit X original y el commit X' rebasado son dos cosas distintas
Y ya hemos aprendido la regla más importante en articulos anteriores.
NUNCA se hacen operaciones que reescriben la historia en ramas públicas, incluido rebase.
Si tú haces rebase de main en tu ordenador y lo subes (forzando):
- Has cambiado la historia.
- Tus compañeros siguen teniendo la historia “antigua” en sus ordenadores.
- Cuando intenten sincronizar, Git verá dos historias divergentes e incompatibles 💥.
- El resultado será un caos de commits duplicados y conflictos horribles (y te mandarán una cabeza de caballo a tu casa).
¿Cuándo SÍ usar Rebase?
En ramas locales o en ramas remotas que solo tú usas.
- Para limpiar tu rama
featureantes de hacer un Pull Request. - Para actualizarte con
mainmientras trabajas solo.
