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

[@CodelyTV]

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

[@monoeze]

Squash, para equipos chicos o muy dinamicos con branches cortos. Merge para el resto. slds

[@tantumDicoQuodCogito]

Merge commit, totalmente de acuerdo, también me gusta tener el detalle de la trazabilidad de los commits

[@CarlosFioriti]

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

[@miguelbemartin]

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!

[@atarconcet]

Totalmente de acuerdo y encima si hay equipos que usan una rama como develop aparte de master/main, se prefiere que ella (develop) sea lineal y no tenga todos los commits de desarrollo de los feature branches, en fin son estilos, gracias

[@cardozoveronica]

Llegué a este video en el momento justo, cuando tenemos que diseñar la estrategia para el equipo. Se han pasado chicos, esta genial! Gracias

[@emiliollamasalba3759]

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

[@emiliollamasalba3759]

Aunque nunca force push. La estética es secundaria siempre: la historia no se reescribe. Prefiero una ui que lo ponga como queráis (que haga una especie de squash en memoria, solo como efecto visual)

[@compartelo007]

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

[@PhosphorusMoscu-code]

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!

[@b14ckh4wk3]

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

[@davidmarver]

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

[@Valeriano.A.R]

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

[@johnnyelcoste]

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

[@alfoncode]

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

[@jjmuga1]

Excelente video y explicación inmejorable

[@Murzbul]

Viva la libertad carajo!

[@gleycerparra2484]

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.

[@CodelyTV]

Eso es, en este punto del vídeo mezclamos innecesariamente los conceptos, y Dani (el que escribe este mensaje 😅) se refería a "merge" como concepto general de fusionar ramas/trabajo, no al hecho de crear un "merge commit". Así que es tal y como comentas 🙂

[@anibalfernandoantonelli3524]

"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!)

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.

[@White_King]

increible video! muchas gracias muchachos!

[@ricardoinostroza8083]

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

[@tbl6625]

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

[@stephanefabriziomargini1476]

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?

[@programacion3694]

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

[@cachipum]

es sourcetree, muy buen programa, te recomiendo probarlo además 100% gratuíto y para macos y windows. Saludos!

[@cristiam87]

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)

[@vladimiririarte3320]

Gracias por el vídeo!

[@reynaldocartana7171]

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.....

[@wardencode4465]

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

[@Jefferson4026]

El squash es muy útil cuando quieres unirte con otra rama de otro desarrollador antes de ir a master o test Acá se tiene una rama dev donde ahi se hace el merge commit con main, pero entre devs squash

[@yahireduardobravotafur5118]

Depende, de que necesite uso merge o rebase.

[@bloodbahamut]

Merge commit, nada mas que agregar :)

[@ericidrogo]

Son unos cracks

[@MinombreesSergio]

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.

[@JeffreyDeveloperCOL]

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

[@ddomingo]

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

[@cachipum]

es que hacer commits con WIP es de parguelas así de claro... y te lo dice uno que se ha hinchado a hacer WIPs durante años hasta ver la luz jaja

[@cachipum]

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

[@josue10hd]

aguante el merge commit 11:42 💪

[@kingskull619]

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

[@JeffreyDeveloperCOL]

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

[@danielosorio5102]

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.

[@cachipum]

amigo, siempre haz commits cortos en ramas cortas, divide tu trabajo lo más que puedas cuánto más pequeños sean los cambios más sencillo vas a trabajar tú y el resto del equipo... luego siempre antes de merge de tu PR haz un rebase local en tu ordenador por si la rama main ha sido actualizada así solucionas los pequeños conflictos que puedan surgir y ya subes una rama limpia y lista para merge. Esto siempre es subjetivo, pero bajo mi punto de vista es la forma más profesional de trabajar. Saludos!

[@83MrLeo]

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... 🤔

[@HectorMiuler]

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.

[@cachipum]

por supuesto, un rebase en la rama principal, sobre todo si reescribe historial... es bastante hardcore y solo en ocasiones críticas se debería hacer, y además hablarlo con el resto del equipo... a mi una vez me quitaron 6 meses de commits por un tema así y me sentó como una patada en los huevos porque ni se consultó...

[@rafaeljohnoballegutierrez7355]

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

[@theivanv3316]

pull request amigo

[@lenzito]

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. 🤔

[@SimdromKorobase]

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.

[@arroutado]

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?

[@MinombreesSergio]

Sourcetree y gitGraph (de vscode) te sirven tambien en repositorios locales, aunque no le veo beneficio prefiero tener un repositorio privado en un servidor, porsi le pasa algo a mi pc.

[@arroutado]

@@MinombreesSergio manejo muchos servidores y cuentas dentro de ellos, y es interesante una herramienta visual para agilizar la administración. No están en mi pc local

[@MiguelPerez-em8gs]

Siempre rebase!

[@daggoth20]

Saludos muchachos, por cierto Alguien mas piensa que la vida es muy corta para usar Git! jejejejeje

[@DIOH]

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.

[@Murzbul]

Concuerdo.

[@carloseduardocasallasfonse5576]

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.

[@suarezgilberto]

Rebase

[@carloscorrea_dotpy]

Squash & Merge

[@daniels026]

Merge commit para no olvidarse del histórico

[@farid5434]

merge porque no e investigado los otros,asta este video

[@mkGarf]

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.

[@hacking-multiboot904]

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

[@francisconhernandez9948]

merge commit

merge-commit

[@mayordan9187]

Squash !!!!!

[@nicolasezequielmelluso3273]

Squash

[@edgardejesusmendozaortegon7655]

mergee!!!!!

[@wilmirosa7076]

Rebase + Squash

[@user-JN33]

rebase

[@ferxxodev]

merge

[@carlostirado8456]

squash

[@logan76able]

merge commit, diógenes al poder.

[@pablor123]

Merge always

[@TheMarcelitto]

team merge commit! 🤣

[@dodo11858]

Merge

[@felixinit]

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

[@makiolo]

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

[@ingmoscar2488]

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

[@xoanxose4715]

Yo soy mas de Merge

[@raulcejas3390]

No se le entiende al entrevistado va muy rápido

[@blumoc]

Squash and merge 😂

[@MariodelaCuadraIzquierdo]

Mal de diógenes. Jaja.😂

[@juanmamani2110]

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

[@DIOH]

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

[@danielvenegas5845]

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

[@Thorito]

Rebase

[@soj3da]

Squash

[@Jaxbulid]

rebase

[@markdomkan3525]

merge

[@esaraviam]

squash

[@programandoConFelipe]

Merge

[@JLP487]

merge

[@Metalung]

merge

[@luisalamo2658]

merge