¿Qué hace `git rebase` y para qué se usa?

git rebase reescribe la historia moviendo tus commits para que arranquen desde una base nueva (normalmente la punta de otra rama). En vez de unir dos historias con un merge commit, "reaplica" tus commits uno por uno encima de la otra rama, dejando un historial lineal y limpio.

Imagina que trabajaste en feature a partir de un commit viejo de main, y mientras tanto main avanzó. Tienes dos formas de ponerte al día:

• Merge: unes ambas historias con un merge commit (queda un historial ramificado).
• Rebase: tomas tus commits de feature y los vuelves a aplicar encima del último commit de main, como si hubieras empezado a trabajar desde ahí. El resultado es una línea recta, sin merge commit.

"Reescribir la historia" significa que Git crea commits nuevos (con hashes distintos) para tus cambios, aunque el contenido sea el mismo. Por eso el rebase es peligroso en ramas compartidas: cambia los identificadores de los commits que otros podrían tener.

# Estoy en feature y quiero ponerla al día con main usando rebase
git switch feature
git rebase main
# Git reaplica mis commits de feature encima del último commit de main
# Salida: Successfully rebased and updated refs/heads/feature.

# Si aparece un conflicto durante el rebase:
# 1. Lo resuelves en el archivo
# 2. git add archivo
# 3. Continúas (NO se usa git commit aquí)
git rebase --continue

# Si te arrepientes y quieres cancelar todo el rebase:
git rebase --abort

# Rebase interactivo: reordenar, combinar (squash) o editar commits
git rebase -i HEAD~3

Hacer rebase de una rama que ya está compartida/publicada. Como el rebase crea commits nuevos con hashes distintos, tus compañeros que tenían los commits originales tendrán historias divergentes y conflictos difíciles. Otro error: durante un rebase con conflictos, intentar cerrar con git commit en vez de git rebase --continue.

"git rebase reescribe la historia: toma mis commits y los reaplica encima de una base nueva, normalmente la punta de otra rama, dejando un historial lineal sin merge commit. Lo uso para poner mi rama al día con main de forma limpia, o con -i para ordenar y combinar commits antes de un PR. Como crea commits nuevos con hashes distintos, nunca rebaseo una rama que ya compartí con el equipo."