Rebase: qué es, en qué se diferencia de Merge y principio de funcionamiento

¿Qué es Rebase?

Rebase (rebasing) es una operación de Git que traslada commits de la rama actual a un nuevo punto base. En lugar de crear un merge commit, rebase toma cada commit de la rama origen y lo aplica uno por uno sobre la nueva base. El resultado es una secuencia lineal de commits sin bifurcaciones.

El nombre rebase proviene de “re-base” — cambiar la base. Mientras que merge combina dos ramas en un solo punto, rebase efectivamente mueve toda tu rama a una nueva ubicación, haciendo que parezca que comenzaste el desarrollo desde el estado actual de la rama destino. Esto crea la ilusión de un trabajo perfectamente secuencial.

Según Atlassian, 2025, los equipos que usan rebase para ramas de características dedican un 30% menos de tiempo a analizar el historial de commits en comparación con los equipos que usan exclusivamente merge. El historial lineal simplifica git blame, bisect y la visualización del log mediante git log --oneline.

Diferencia fundamental con Merge

Merge une ramas creando un commit con dos padres. Rebase reescribe el historial: se crean nuevos commits con nuevos hashes, aunque sus cambios sean idénticos a los originales. Esto significa que rebase cambia los identificadores SHA de los commits, lo cual es crítico para las ramas públicas.

Cómo funciona Rebase

El mecanismo de rebase consta de cuatro pasos: Git determina el ancestro común (merge base) de la rama actual y la destino, luego aplica secuencialmente cada commit de la rama actual sobre la rama destino. Si surge un conflicto en algún paso, rebase se detiene y espera resolución.

# Situación inicial: la rama feature está 3 commits detrás de develop
git checkout feature/new-login
git rebase develop

# Git toma 3 commits de feature y los aplica sobre develop
# Si no hay conflictos — rebase se completa automáticamente
# Si los hay — Git se detiene en el commit conflictivo

Después del rebase, la rama de característica contiene todos los commits de develop más sus propios commits, que aparecen como una continuación de develop. Esto permite fusionar en develop mediante fast-forward sin crear un merge commit.

Proceso paso a paso

Veamos un ejemplo detallado: un desarrollador creó una rama de característica a partir de develop, hizo dos commits, mientras tanto otros desarrolladores añadieron tres commits a develop. Rebase moverá los dos commits de la característica a una nueva posición, creando sus copias con nuevos SHA.

# 1. Crear una rama feature
git checkout -b feature/payment-refactor develop

# 2. Hacer commits en feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Actualizar develop (trabajo de compañeros)
git checkout develop
git pull

# 4. Rebase de feature sobre el nuevo develop
git checkout feature/payment-refactor
git rebase develop

# 5. Ahora feature se puede fusionar mediante fast-forward
git checkout develop
git merge feature/payment-refactor

Si surge un conflicto en el paso 4, Git se detiene en el commit problemático. El desarrollador resuelve el conflicto, ejecuta git add y luego git rebase --continue. Para saltar un commit — git rebase --skip, para cancelar todo el rebase — git rebase --abort.

Omisión automática de commits vacíos

El flag --empty controla el comportamiento de rebase ante commits vacíos — situaciones en las que todos los cambios de un commit ya están presentes en la rama destino. Por defecto, rebase se detiene y pide una decisión. Con --empty=drop, Git omite automáticamente esos commits sin detenerse, acelerando el rebase masivo con gran cantidad de commits.

Rebase interactivo

El rebase interactivo (git rebase -i) es una herramienta potente para editar el historial de commits. Abre un editor con una lista de commits y comandos clave: pick (mantener), reword (cambiar mensaje), edit (cambiar contenido), squash (fusionar con el anterior), fixup (fusionar sin mensaje), drop (eliminar).

# Rebase interactivo de los últimos 4 commits
git rebase -i HEAD~4

# El editor abrirá un plan de rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Cambiamos a:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Resultado: tres commits (pantalla de inicio de sesión, validación, diseño) se fusionan en uno, y el commit con comentarios se elimina. Esto permite enviar un historial limpio para la revisión de código sin borradores ni correcciones. El rebase interactivo es una herramienta estándar para preparar una rama de característica antes de un Pull Request.

Rebase vs Merge: comparación

Rebase y Merge resuelven el mismo problema — integrar cambios — pero de formas fundamentalmente diferentes. La elección entre ellos depende del tipo de historial que quieras ver en git log y de quién más trabaje con tu rama.

Regla práctica: usa merge para integrar en ramas compartidas (develop, main) y rebase para actualizar ramas de características personales. Muchos equipos combinan ambos: rebase de la característica sobre develop, luego --no-ff merge en develop.

Impacto en git bisect

Git bisect es una herramienta para encontrar el commit que introdujo una regresión. Al usar merge, git bisect recorre correctamente los merge commits, considerando a ambos padres. Con rebase, bisect funciona más rápido porque el historial es lineal y no requiere bifurcaciones. Sin embargo, si el rebase se hizo después de que los commits se hicieran conocidos por el equipo, los SHA originales se pierden y bisect puede no encontrar el commit problemático.

Cuándo usar Rebase

Rebase es óptimo en tres escenarios: preparar una rama de característica para un Pull Request, actualizar una rama personal al estado actual de main/develop y limpiar el historial antes de fusionar. En cada caso, rebase mejora la legibilidad del historial sin riesgo para el trabajo en equipo.

Antes de un Pull Request, se recomienda hacer un rebase interactivo para combinar commits de borrador (WIP, correcciones post-revisión) en unidades lógicas significativas. Esto facilita la revisión de código: el revisor ve no 15 commits menores sino 3-5 cambios estructurados con mensajes claros.

Para actualizar una rama de característica, rebase es preferible a merge porque no crea merge commits innecesarios. Si haces periódicamente git rebase develop dentro de la rama de característica, la fusión final no tendrá una cascada de 10 merge commits — solo commits limpios de la característica sobre develop.

La limpieza del historial mediante rebase interactivo antes de fusionar permite ocultar correcciones menores (erratas, formato) y agrupar commits por funcionalidad. Los mensajes de Git deben seguir la convención Conventional Commits (fix:, feat:, refactor:, docs:), que genera un changelog automático.

Riesgos y reglas de Rebase

Rebase es una operación peligrosa si se aplica incorrectamente. El principal riesgo es reescribir el historial publicado. Si un desarrollador hace rebase de una rama que otros ya han subido y están usando, sus copias locales se desincronizarán y tendrán que hacer un force-pull con riesgo de pérdida de datos.

• Regla de oro: nunca hagas rebase de commits que ya existen en el repositorio compartido. Esto aplica a cualquier rama accesible por otros miembros del equipo
• Force push: después de rebasar una rama de característica local, se requiere un push con el flag --force-with-lease, que es más seguro que --force porque verifica si alguien más ha actualizado la rama en el servidor
• Pérdida de contexto: rebase destruye la información sobre cuándo y desde qué rama se creó la rama de característica. Si es importante conservar las fechas de creación de la rama, usa merge
• Conflictos: durante el rebase, los conflictos deben resolverse para cada commit individualmente, lo que puede ser tedioso con un gran número de commits

Para minimizar riesgos, sigue esta regla: rebase solo para ramas personales que no hayan sido publicadas. Si una rama ya está en el repositorio compartido, usa merge con --no-ff. Si necesitas rebasar una rama publicada, avisa al equipo y coordina el force push con antelación.

La protección automática contra rebase peligroso se implementa mediante hooks del lado del servidor: un hook pre-receive en el servidor Git puede verificar si el push reescribe commits publicados. GitHub y GitLab proporcionan protección integrada para ramas protegidas — el force push se bloquea a menos que un administrador retire la protección.