Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir? 

Y a tí ¿Qué estrategia te gusta más? ¿Merge commit, Squash o Rebase?

Cocuerdo contigo Javi, considero la mejor opción a "Merge Commit" ya que aporta lo mejor de ambos mundos.

Casi casi me convence Javi también, pero nosotros usamos "Squash and merge" porque normalmente el histórico dentro de la feature branch no queda tan limpia como en los ejemplos, hay mucho, "fix test", "fix", "bla bla", y suele haber muchos commits que no tienen relevancia. Además intentamos que sean pull requests pequeñitos, por lo que no hay muchos cambios en un mismo PR, en caso que tengamos que volver atrás, el PR es una unidad suficiente y no necesitamos más granularidad. Buen video chicos!

Merge para integrar código en Main (con cherry-pick si fuera necesario). Rebase para integrar código desde Main a ramas secundarias. Nunca squash, que la historia se mantenga

explicación superclara! gracias y enhorabuena por el vídeo!

Enhorabuena! más conversaciones de este tipo!! :)

Con cuerdo con Javier conviene merge commit squash solo en el caso de que algo sea suuuuper estable supongo, fue muy util mostrar de manera grafica todo, si quieren lo mismo para Visual Studio Code esta Git Graph!

que agradable video, buenos argumentos a diferentes modo de usos con diferentes casos de usos. sigan asi

increible video! muchas gracias muchachos!

Excelente video y explicación inmejorable

Javier, 101% de acuerdo con le merge por lo que has explicado de sus beneficios

Gracias por el vídeo!

yo concuerdo con javier, use la estrategía de merge commit en un trabajo pasado y todo era mucho mas claro , muy legible

Totalmente "team Javi". Llevo toda la vida haciendo merge commit por la misma razón: tengo diogenes-digital y a mucha honra 😁

Son unos cracks

Merge commit, pero al oír sobre rebase me llamo mucho la atención y lo tomaré mucho más en cuenta

Buen video!!! Github ofrece la opcion de restore branch una vez la has eliminado. Me quedo con el Squash, por esa razón. Puedo recuperar esas ramas.

"Merge commit" y $git log --all --decorate --oneline --graph Pero es verdad que con la herramienta gráfica se ve bien chulo (se me pego el chulo español... saludos desde Argentina!)

yo uso rebase commit configurando con no-ff. Tienes el mismo grafo que merge-commit, pero ademas las ramas que se integran no se cruzan (en el caso que se no se integren en el orden en el que se crearon)

Jajjajka por fin alguien me me entiende, arriba el merge!!

Muy bueno el video, luego de verlo me puse a probar el rebase porque no lo había utilizado anteriormente y me encontré con un gran problema que no se como resolver: si tengo un feature-branch al que quiero hacer rebase para traerme los últimos en main y ese feature-branch tuvo algún merge-commit porque hubo conflictos en algún pull por ejemplo esos merge commit son ignorados en el rebase y hay que volver a hacer la resolución de conflictos! Eso me parece que me anula totalmente la idea de usar rebase en ese caso.....

Merge commit, nada mas que agregar :)

Rebase con la condición que únicamente cuando soy el único que usa la rama

Squash es siempre indicio de un repo sano y saludable, para mi ver otras cosas indica ciertas malas prácticas, como puede ser mucho tiempo con ramas largas o de muchos commits, falta de comunicación a la hora de hacer deployments o integraciones... entra otras posibilidades... y respecto al histórico pues si tienes un proyecto saludable con el propio histórico de main debería ser suficiente referencia, en la práctica cuántas veces mirado la vista atrás en la que hayáis necesitado esos metadatos que se pierden en el squash? pocas, pocas

fast-forward / rebase SIEMPRE Pero solo si sigues la regla de 1 commit por feature, esto se cumple con el rebase -i o el ammend, como el equipo decida. Con esto igual automatizas el CHANGE-LOG basado en el commit historry

Siempre rebase!

el video de 10. Os habéis centrado en la rama main pero... ¿utilizaremos la misma estrategia si tenemos develop o partimos de hotfix?

que bien me vino este video, soy nuevo en el mundo de git y con este video aprendi bastante me encanta como explica javi como siempre explica todo tan facil sin marear tanto por cierto que programa es el que usas en 13:51? yo estoy usando git desktop pero ese tiene mejor pinta

En el min 22:34 cuando dice que hace un squash, rebase and merge se refiere a que si bien en el botón dice "squash and merge" no es un "merge commit", es mas parecido a un "squash and commit" como bien dice Javi, pero entiendo que se refieren a merge en ese caso no al método "merge commit" sino a la acción de unir las ramas.

Depende, de que necesite uso merge o rebase.

Opino igual Javi. Yo también soy fan del merge commit. El rebase lo veo súper arriesgado la verdad, y el squash es útil si hay mucho commit con WIP de por medio

Hola. He alucinado un poco con el rebase que haceis vosotros en el video, porque cuando yo hago rebase desde la terminal con Git, no me conserva la rama. Es decir, que después del rebase, solo ha quedado 1 rama no 2 como se vé en el minuto 10:48. Como es que vuestro rebase funciona diferente?

Hasta ahora había trabajado con merge y me molestaba un poco los commits de mergeo, me estaba planteando squash por tener la rama main más limpia, ahora ya no tengo tan claro si cambiar... 🤔

El Squash merge, se podría hacer con un rebase interactivo

Yo soy de Merge commit pero desde siempre y nunca he entendido el Rebase, me explico: estamos usando un control de versiones y como control de versiones que es veo 100% necesario tener la granularidad que ofrece el merge commit, el rebase deja muy sucio la Main y el Squash "elimina" informacion útil.

Git rebase bien usado llevas una sola linea de historial de log donde ves paso a paso todos los cambios que se han generado sin necesidad de estar aplicando filtros especiales al git log. Con ese historial limpio puedes generar una visual mas atractiva y ademas generar un CHANGELOG lineal. El git merge embasura mucho pues llena mucho de lineas paralelas el log asi las borres las ramas. La mejor forma de usar el rebase es que todo PR antes de ser publicado haga un rebase con el origin/main a la rama trabajada para que cuando se haga el merge rebase de la rama del feaure quede despues de los ultimos cambios y quede bien limpio el historial.

En mi rama de trabajo me gusta el rebase, claro si se me hace muy muy complicado pues recurro al merge. Pero en la ramas principales tiene que ser un merge de verdad.

Squash & Merge

Yo solo concia el Merge commit, y ahora que veo a los otros, pienso que son versiones inferiores, ¿enserio sacrificarian una posible depuracion por que "se ve sucio"? como dice Javier con el visualizador grafico puedes ver lo que quieras ver, osea no le veo beneficio alguno a borrar esa meta data. Y si yo hago comits en plan, bla bla bla, save changes y similares. Pero me ha servido varias veces ver el historial de cambios modular en ramas trabajadas por otros desarrolladores para ver porque hicieron x cambios en x archivos, ademas cuando se trabaja con un servidor de pruebas unico para muchos desarrolladores hay cosas que quedan incompletas en la rama de desarrollo y me piden devolver o integrar con la rama de QA, asi que puedo ver que cosas si y que cosas estan a medias, cuando hay conflictos tener esta modularidad es super conveniente.

Yo creo que no es necesario buscar uno, yo pienso que se puede dar por funcionalidad relevante, si un grupo de cambios pertenece a una funcionalidad sería rebase, si hay varias funcionalidades sería merge commit. 🤔

Squash !!!!!

Te apoyo Javier. Merge commit por algo es el clásico. No hay absolutamente ninguna ventaja en los otros para proyectos complejos: Rebase tiene sentido en proyectos de rama única en los que no manejas versiones o cuando por algún motivo has sacado ramas de tus propias features. Y squash cuando realmente la granularidad no tenía sentido y DEBÍA ser reunida en un solo commit.

Rebase

Buenos dias desde Colombia medellin ciudad de la eterna primavera., por lo pronto estoy aprendiendo a utilizar los comandos basicos de git con dos ramas sobre las cuales he hecho varios commits sin problema pero cuando intente realizar merge hice un lio barbaro que no entendi, por tal razon estoy tratando de comprender como funciona merge viendo su video.

Merge commit para no olvidarse del histórico

Hola! He probado Sourcetree pero parece que solo sirve para repositorios GitHub, GitLab, BitBucket, etc. No hay una herramienta similar para poder trabajar con repositorios git privados en mi propio servidor?

Squash

merge commit

merge-commit

merge porque no e investigado los otros,asta este video

Alguien me puede comentar a que se refieren cuando dicen 'PR'? Por favor.

mergee!!!!!

utilizar merge para el ambiente Dev y squas para main 🤔 para mi es la mejor opción, pero no lo se Rick solo soy el becario XD

merge

rebase

squash

Rebase + Squash

Personalmente no le veo sentido a los merge commits, más con los descriptions genéricos, prefiero la linealidad del squash and merge con un description semántico.

Merge always

Merge

merge commit, diógenes al poder.

Rebase, y pues con squash jejeje, a menos q el historial sea muy crítica

16:11 la estrategia de merge idónea. Síndrome de Diógenes.

merge enlaza, rebase copia, y squash copia y compacta.

Yo soy mas de Merge

Squash and merge 😂

Mal de diógenes. Jaja.😂

El clásico merge commit, el resto no convence. Puro humo

Como me enferma el mal uso de la palabra "mergear", lo que realmente debería decidirse es "fusionar"

Maater se llamara siempre master, que luego los ofendiditos, copitos de nieve, y hombres con florcitas le cambien el nombre a main, es solo payasada

Rebase

Squash

merge

rebase

squash

Merge

merge

merge

merge