Cuando quieres traer los cambios de una rama a otra, Git te ofrece dos herramientas: merge y rebase. Producen historiales distintos, con ventajas diferentes.
Merge: preservar el historial real
git merge toma las dos ramas y crea un merge commit que une sus historias. El grafo se mantiene fiel a la realidad: puedes ver exactamente cuándo divergió la rama y cuándo se integró.
El resultado en git log --graph parece dos líneas paralelas que convergen en un solo punto. Es legible, rastreable y no destructivo.
Rebase: linealizar el historial
git rebase reproduce tus commits encima de otra rama. El resultado: un historial perfectamente lineal, como si siempre hubieras trabajado después de los últimos commits de main.
Git mueve cada commit de mi-feature uno a uno, reproduciéndolos después del último commit de main. El historial se convierte en una línea recta, sin merge commit.
Comparación rápida
| Merge | Rebase | |
|---|---|---|
| Historial | Preservado, con merge commit | Linealizado, commits reescritos |
| Seguro en rama compartida | Sí | No |
| Legibilidad del grafo | Muestra las ramas reales | Limpio y lineal |
Cuándo usar cada uno
- Merge: para integrar una feature en
main, para mantener un rastro claro de dónde vienen las cosas. La opción por defecto en un contexto colaborativo. - Rebase: para limpiar el historial de una rama local antes de abrir un pull request. Haces
git rebase mainpara que tu PR se aplique limpiamente sobre el código más reciente.
Un flujo habitual: trabajas en mi-feature, ejecutas git rebase main para ponerte al día sin merge commits parásitos, y luego abres una PR. GitHub fusiona entonces con un merge commit oficial.