Hola Alfonso,

Muchas gracias por la información me he aclarado mucho mas, yo normalmente utilizo merge para ramas production (compartidas) y rebase para las ramas de desarrollo.

gracias, Un saludo

Hola Jose:

Gracias por el comentario. Respondiendo a tus preguntas:

• No, un fast-forward no es lo mismo que un rebase, aunque a veces el resultado sea el mismo lo que hace internamente git con los commits no tiene nada que ver.
• No, no siempre usamos merge para aplicar cambios, utilizamos merge, rebase y a veces pick y cherry-pick

Un merge con fast-forward se produce cuando puedes moverte de una rama a otra por el grapho de objetos en una única dirección, es decir, si puedes ir de una rama a otra sólo bajando o subiendo. Si tienes que subir y luego bajar (o viceversa) necesitas un merge commit para poder incorporar los cambios de una rama en la otra.

Con respecto al rebase, te pongo un ejemplo real. En un proyecto que tengo ahora tengo tres ramas de pruebas en las que estoy probando cosas. Por otro lado, tengo la rama development en la que voy desarrollando el proyecto. Cada pocos días, incorporo las modificaciones de «development» en las ramas de prueba para estar al día. Esto lo hago con un rebase en lugar de un merge. ¿El motivo? me ahorro un montón de merge commits que no me aportan nada y me enguarrinan la historia del repositorio. Como son mías y no las usa nadie (están en mi remoto pero nadie las utiliza…y si lo hace ya sabe lo que se va a encontrar) no hay problema.

Por otro lado, cuando hago un hotfix en la rama «production», me lo llevo a a la rama develop usando un merge. Si lo hiciese con rebase, estaría modificando los commits. Esto supone un problema ya que estas dos ramas están compartidas y al borrar unos commits y cambiarlos por otros con el rebase volvería locos a mis compañeros.

¿Te ha aclarado algo la respuesta?

Un saludo,

Alfonso

¿El merge con fast-fortward es lo mismo que el rebase?
¿Utilizais siempre merge apra aplicar cambios?

gracias, Un saludo