Tu rama de funcionalidad va por detrás de main y necesitas el trabajo nuevo. Git merge vs rebase es la elección entre dos formas de conseguirlo, y ambas son correctas. Se diferencian en cómo queda el historial después.

Creamos un repositorio diminuto, ejecutamos ambos comandos y pegamos la salida real, para que compares el resultado en lugar de imaginarlo. ¿Nuevo en Git? Empieza con nuestro tutorial de Git para principiantes.

Qué hacen git merge y git rebase

git merge toma las puntas de dos ramas y las combina. Si ambas tienen commits nuevos, Git crea un commit de fusión con dos padres. Nada de lo que ya existe cambia.

git rebase toma los commits exclusivos de tu rama, los aparta, mueve tu rama a la punta de la otra y luego los reproduce uno a uno. Los commits reproducidos son commits nuevos con hashes nuevos, aunque sus cambios sean los mismos.

Git merge en la práctica

Nuestro punto de partida: el commit A en main, dos commits (F1, F2) en feature y un commit más (M1) añadido después a main. Ahora fusionamos main en feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

El gráfico muestra la historia real: dos líneas de trabajo que se unieron. Los commits originales F1 y F2 conservan sus hashes. El coste es un commit de fusión adicional y, en un proyecto activo, el gráfico se convierte en una telaraña.

Git rebase en la práctica

Mismo punto de partida, pero ahora hacemos rebase de feature sobre main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

El historial es una línea recta, como si hubieras empezado tu trabajo después de M1. Fíjate en los hashes: F1 era 5a71e3c y ahora es bf9149e, y F2 pasó de 082cc6a a 1ff474b. Git los reescribió, y por eso el rebase exige cuidado.

Merge vs rebase lado a lado

La regla de oro del rebase

No hagas rebase de commits que existen fuera de tu propio repositorio. Tras un rebase, tu rama ya no coincide con la copia del servidor, así que subirla exige un push forzado. Si un colega construyó trabajo sobre los commits antiguos, su historial ahora discrepa del tuyo, y arreglarlo es doloroso.

Hacer rebase de tu rama privada de funcionalidad está bien. Hacerlo de main o de cualquier rama que otros usen, no.

Un flujo de trabajo seguro para equipos

Esta rutina mantiene el historial limpio sin sorprender a nadie. También es lo que usan la mayoría de los equipos antes de su pipeline de CI, como el de nuestra guía de GitHub Actions CI/CD.

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease se niega a sobrescribir la rama del servidor si alguien ha subido cambios desde tu último fetch, algo que un --force normal destruiría sin avisar. Cuando se apruebe el pull request, fusiónalo en main.

Cómo deshacer un rebase fallido

Un rebase parece destructivo, pero los commits antiguos permanecen un tiempo en el reflog de Git, así que puedes volver atrás.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Crea una rama de respaldo con git branch backup antes de cualquier rebase arriesgado y recuperar será un solo comando. ¿Ejecutas una base de datos o herramientas en contenedores? Mira nuestro tutorial de Docker para principiantes.

Para terminar

Merge conserva la verdad, rebase la mantiene ordenada. Usa rebase para refrescar tu propia rama, merge para entregarla y nunca reescribas un historial del que dependan otras personas.

Preguntas frecuentes

Sigue aprendiendo