Rama Git rebase: cómo rebase de forma segura, paso a paso

Para cambiar la base de una rama, búsquela, cámbiela y reprodúzcala en la nueva base: `git fetch origin`, `git switch topic`, `git rebase origin/main`. Git deja a un lado las confirmaciones de su rama, mueve la rama a la punta de origin/main y luego vuelve a aplicar las confirmaciones una a la vez. El historial se mantiene en línea recta sin commit de fusión. Cada confirmación repetida obtiene un nuevo hash, por lo que una rama que ya hayas enviado necesita git push --force-with-lease después.

¿Qué le hace git rebase a una rama?

Digamos que topic tiene dos confirmaciones propias y main ha ganado tres desde que comenzó la rama. Rebasar actualiza ese punto de partida sin fusionar main en su rama:

# before
A---B---C---D---E   origin/main
     \
      F---G         topic

# after git rebase origin/main
A---B---C---D---E   origin/main
                 \
                  F'---G'   topic

F' y G' contienen los mismos cambios y mensajes que F y G, pero son confirmaciones nuevas con hashes nuevos, porque sus padres cambiaron. Una fusión desde el mismo punto de partida mantendría ambas líneas y agregaría una confirmación con dos padres. La lección sobre fusionar versus rebase muestra ambos en un gráfico.

¿Cómo rebase una rama de forma segura, paso a paso?

Inspeccione primero, conserve la punta anterior, vuelva a reproducir y luego pruebe. Los primeros tres comandos no reescriben nada:

# 1. update origin/main, your files stay as they are
git fetch origin

# 2. list the commits Git will replay
git log --oneline origin/main..topic

# 3. keep a name on the old tip
git branch topic-backup topic

# 4. replay
git switch topic
git rebase origin/main

Deténgase en el paso 2 si la lista tiene una confirmación que no reconoce, porque significa que la rama no comenzó donde pensaba. Cuando finalice la rebase, ejecute git status para confirmar que finalizó y luego ejecute sus pruebas. Una rebase sin conflictos aún puede alterar el comportamiento.

Nombra la base cada vez. Un git rebase simple utiliza el upstream de la rama, que a menudo es origin/topic y no main. Para mover una rama que comenzó desde otra rama característica, nombre también la base anterior: git rebase --onto main old-base topic. La lección sobre rebasar trabajo no publicado practica esto en un gráfico real.

¿Cómo soluciono los conflictos durante un rebase?

Git aplica tus confirmaciones una a la vez, por lo que puede detenerse más de una vez, incluso en las mismas líneas. Corrija solo la confirmación en la que Git se detuvo, ya que las posteriores aún no se han aplicado:

# edit the file and remove the conflict markers, then
git add path/to/file
git rebase --continue

Si repites el mismo conflicto con frecuencia, git config rerere.enabled true registra tu resolución y la reutiliza. Verifique cada resultado reutilizado, porque la respuesta de ayer puede estar incorrecta en el código de hoy. La lección sobre continuar, omitir y cancelar analiza cada caso y cómo resolver conflictos de fusión cubre la lectura de los marcadores.

¿Cómo verifico un rebase antes de hacer push?

Compara la serie antigua con la nueva antes de que nadie la vea:

# old and new commits, matched pair by pair
git range-diff origin/main topic-backup topic

# everything the branch adds to main, as one diff
git diff origin/main...topic

# the shape of the history
git log --graph --oneline --decorate origin/main topic

git range-diff muestra cuándo una resolución de conflicto cambió un parche o cuándo desapareció una confirmación. El código que se compila aún puede ocultar una prueba descartada o una condición modificada, y aquí es donde se detecta.

¿Cómo deshago un rebase?

Mientras se está ejecutando, use git rebase --abort. Una vez que haya terminado, mueva la rama nuevamente a la punta anterior. Marque git status primero, porque --hard descarta los cambios no confirmados:

git reset --hard topic-backup

# no backup? find the old tip in the reflog
git reflog show topic
git reset --hard <old-tip-hash>

La guía para deshacer un reinicio, rebase o confirmación cubre el reflog con más profundidad.

¿Cómo hago push de una rama tras el rebase?

Se rechaza un envío normal porque la rama remota aún conserva las confirmaciones antiguas y Git ve una actualización que no es de avance rápido. Verifique lo que está a punto de reemplazar y luego solicite un contrato de arrendamiento:

git fetch origin
git log --oneline topic..origin/topic
git push --force-with-lease origin topic

Ese git log debería enumerar solo tus confirmaciones anteriores. Cualquier otra cosa es trabajo de un compañero de equipo, así que detente y tráelo primero. --force-with-lease reemplaza la rama remota solo si todavía está donde la vio la última vez, y --force simple no tiene tal verificación. Las recuperaciones en segundo plano actualizan ese valor, por lo que los scripts pueden nombrar la confirmación que esperan: git push --force-with-lease=topic:<expected-hash> origin topic.

¿Debo cambiar la base o fusionar esta rama?

La guía para cambiar la base de una rama tiene todas las opciones, y forzar el envío con arrendamiento cubre el envío. Para aplastar, reformular o reordenar a lo largo del camino, lea rebase interactivo en una GUI.