Git merge

• Operación: git merge develop
• Objetivo: integrar las modificaciones de una rama (develop) en otra (feature/login).
• Proceso: Git crea un "commit de fusión" nuevo que tiene dos padres, uno por el último commit de cada rama. Eso conserva el historial tal como ocurrió.
• Resultado: el historial de la rama feature/login muestra una estructura con una bifurcación, donde el commit de fusión combina los historiales de las dos ramas.

Git rebase

• Operación: git rebase develop
• Objetivo: volver a aplicar los commits sobre la cima de otra rama base.
• Proceso: el rebase toma las modificaciones hechas en la rama feature/login y las reaplica sobre la cima de la rama develop.
• Resultado: el historial queda lineal, como si las modificaciones se hubieran hecho justo después de los últimos cambios de develop.

Diferencias clave

• Preservación del historial: merge no modifica el historial existente, mientras que rebase reescribe el historial de los commits para dejarlo lineal.
• Resolución de conflictos: con merge, los conflictos se resuelven al final del proceso de fusión; con rebase puede hacer falta resolver conflictos a lo largo del proceso, a medida que se reaplica cada commit.

En resumen, merge se usa para conservar un historial preciso de los cambios, mientras que rebase se prefiere para simplificar el historial antes de integrar una rama de funcionalidades.

2 - ¿Sigue sin quedar claro?

Git merge

• Qué hace: fusiona los cambios de dos ramas en una sola. Combina los caminos de desarrollo.
• Cómo funciona: crea un commit nuevo que tiene dos padres. Cada padre representa el último commit de cada rama antes de la fusión.
• Historial de commits: el historial muestra con claridad cuándo divergieron y se fusionaron las ramas. Parece un gráfico con un punto en el que dos líneas se juntan para formar una sola.

Git rebase

• Qué hace: cambia la base de tu rama de funcionalidades para que parezca creada a partir del último commit de la rama develop.
• Cómo funciona: toma los commits de la rama de funcionalidades y los "reproduce" uno a uno sobre la cima de la rama develop.
• Historial de commits: el historial queda lineal. No se ve una bifurcación como con merge. Da la impresión de que todos los cambios se hicieron en orden, sin desarrollo en paralelo.

¿Por qué elegir uno u otro?

• Merge: se usa para conservar el historial completo y explícito del proyecto. Es útil cuando quieres ver los puntos exactos en los que se combinaron los cambios.
• Rebase: se usa para crear un historial más limpio y más simple. Es práctico si quieres que el historial parezca una secuencia de desarrollo directa, sin ramas secundarias.

En resumen, si quieres que el historial del proyecto muestre cómo se desarrollaron las funcionalidades en paralelo y se combinaron, usa merge. Si prefieres un historial simple y directo (como si todo se hubiera desarrollado en orden lineal), usa rebase.