Tag Archives: Merge

Diferencias entre rebase y merge en git

A la hora de integrar los cambios realizados en una rama de desarrollo, se puede optar por diferentes formas. Una de ellas, la más tradicional, sería aplicando un parche que previamente hemos recibido por algún medio. Otras formas más lógicas si son cambios propios sería mergear o hacer un rebase de dicha rama hacia la principal. En svn (y cvs) no existe el concepto de rebase, por lo que al moverse a sistemas como git al principio puede ser algo confuso.

No hay mejor forma de visualizarlo que con unas imágenes de los resultados que podríamos obtener. Partimos de esta situación inicial (imágenes sacadas usando gitk):
Rebase vs merge, situación inicial
Y ahora vayamos a las posibles acciones que podríamos realizar para incorporar los cambios de la rama perrea a master:

  • git merge perrea
    Rebase vs merge, realizado merge
  • git rebase perrea
    Rebase vs merge, realizado rebase
  • git merge --squash perrea (&& git commit)
    Rebase vs merge, realizado merge squash

En un merge squash lo que hacemos sería el equivalente a aplicar un parche. Es decir, simplemente se aplican los cambios de dicha rama pero no se asocia con ésta (ni se realiza un commit automáticamente). Esto puede venir bien cuando tengamos muchos commits “sucios” (quien dice sucios, dice poco elegantes, chapuceros, embarazosos, etc…) o que queramos ocultar. Posiblemente útil al integrar cambios a una rama pública en un grupo de trabajo grande.

Entonces, ¿qué es mejor usar?. Que yo sepa, no hay una respuesta absoluta (como en casi todo). Posiblemente sea cuestión de gustos personales. De cara al historial, un rebase hace que luego sea más fácil seguir la evolución, pues un grafo sin ramificaciones es obviamente mucho más simple que uno que las tiene y si podemos simplificar las cosas, ¿para qué complicarnos la vida?.