Buenos días, muy buen video. Solo que por mi parte veo que no se respondió lo que pregunta en el título, si se ven los dos casos de merge y rebase, pero no se responde a la pregunta ¿Cuándo usar cuál?. Todavía me queda la duda de en qué casos es conveniente usar merge y en qué casos es conveniente usar rebase. Gracias.
Yo creo que queda muy claro. Depende de lo que quieras hacer. En primer lugar jamás uses rebase en ramas que son públicas ( las que has hecho push). Luego usa rebase si quieres guardar todo tu historial de commits o usa merge si no quieres guardar el historial de commits, solo los cambios. En rebase ves cada uno de los commits, en merge tienes los mismos cambios pero fusionados en un solo commit. Por seguridad, si tienes dudas, usa siempre merge.
Saludos Javier, no había respondido a tu comentario por que estaba preparando este video que me pediste, ojalá te guste: th-cam.com/video/nqTIbGCzNVk/w-d-xo.html
Otra preguntica, pongo el comentario a parte para no mezclar los temas. Es que me llamó mucho la atención el comando reset --hard, para ir a un commit anterior. Teniendo las ramas de esta forma: feature = id_commit1, id_commit2, id_commit3 develop = id_commit1, id_commit2, id_commit3, id_commit4, id_commit5 La rama feature es mi local y la de develop es en donde se trabaja colaborativamente con otros desarrolladores, dicho esto, id commit 4 y id commit 5 lo han subido otros. Si yo le doy en mi rama feature un reset --hard hacía commit1 y le hago push a la rama de develop. La pregunta es ¿Qué queda en la rama de develop? Tratando de responder a mi pregunta, ¿Quedaría de esta forma al hacer el push de feature a develop? feature = id_commit1 develop = id_commit1, id_commit4, id_commit5 Gracias
Hola que tal, argadeciendo por el aporte, creo que es el primer video que me topo con tu canal y ya me suscribi haber si entendi bien: Entonces Meramente es solo para "mantener" el historico de los commit, cierto?, es decir: Con Merge: podras ver la historia de los commit que se hicieron en un branch o mas bien dicho su "traza" (usando graph), observando como se bifurca o se parte en que punto de la historia y cuando se "integra", generando un nuevo branch o punto para unir ambos cambios. Con Rebase: es hacer un historico "mas limpio" respecto a que si se visualiza su historico (usando graph), solo veriamos una "traza", es decir , como si todos los cambios que hicimos, los hicieramos directos en master (o en el repo donde se haga el rebase), pero no sabriamos asi tan facilmente que fue lo que paso o a partir de que punto se inicio el cambio y al final cuando se quiera unir ambos codigos/cambios (usando rebase posicionandonos desde la rama que queremos unir) se tendra que hacer un merge "manual" para que se integren los cambios, tomando como el ultimo Commit el del ultimo generado en la rama que se hizo rebase (por que se uso fast-forward), se uso el merge fast-forwad- o mas bien dicho , Git uso sin nuestro consentimiento el fast-forward por que implicitamente detecta que se uso un rebase y merge?, es decir es opcional que use fast-forwad o eso puede cambiar (aun nose para que pero ,ver la posibilidad y que se haria o por que hacerlo distinto) Una duda, mas :) , aun tengo la mala practica o costumbre de realizar un backup del repositorio y del codigo que quiero integar en alguna ruta de la pc, despues lo que hago, es copiar y pegar algunos archivos (los que son nuevos) y los archivos que se que tienen cambios los comparo (con winmerge o algun otro comparador) manualmente y hago los cambios, y en git solo doy "git add" y "git commit". Sin embargo quiero irle perdiendo el miedo y practicar para evitar hacer esas comparaciones y modificaciones manuales, y hacerlo con git, nose si solamente sea posible ir verificando con "git diff" y haciendo los merge o rebase, o como podria hacerlo, alguna herramienta con git para abrir el comparador y elegir que lineas de codigo dejar o quitar? PD: perdon por la carta :)
¡Qué pena que no siguieras con los videos de los patrones o con más ejemplos de ello y de lo relativo a SOLID!
3 ปีที่แล้ว +2
Saludos Pedro, la serie de patrones de diseño va a continuar, el video que estoy preparando es el de cadena de responsabilidad. Tenía mucho tiempo sin subir video y este tema me gusto. Espero en unos días poder subir otro de patrones, en el inter comenzaré a subir videos de diferentes herramientas.
Excelente vídeo, mi pregunta es su de alguna forma se puede configurar para que muestre el commit con la nota del merge, así uno lo tiene mas claro, o forzar a realizar un merge sin el fast-forward
¿Cómo podrías crear una rama a partir de otras 2 ramas? Vale decir crear una tercera rama que contenga los commits de una primera rama y una segunda rama
Gracias a vos lo entendi! Pero una consulta, que diferencia hay entre git rebase y git pull --rebase? Lo he buscado pero no lo entiendo. Me suscribi a tu canal
2 ปีที่แล้ว +1
Saludos bro, el pull lo que hace es descargar los cambios del repositorio remoto, y con las banderas --rebase o --merge, es la estrategia que usará git para fusionar los cambios, espero esto te sirva. Saludos!
Muchas gracias por el video, me fue de gran ayuda!! Una pequeña consulta, cómo se llama la app que usabas a la derecha donde se iba viendo los commit y ramas creadas?
3 ปีที่แล้ว +2
Gracias a ti Luis por ver el video, la app se llama GitUp (github.com/git-up/GitUp) no solo sirve para visualizar el repositorio en modo gráfico, tiene muchas otras funciones. Saludos!
se ve bueno el video, pero no es muy real este tipo de situaciones... Por lo general siempre se tiene una rama master, una develop y una feature donde se trabajara , esta rama feature se obtiene siempre de develop. Los problemas que suceden son que alguien actualizo develop , y cuando quieres pasar tus cambios a develop entonces tienes problemas con MERGE si alguien actualizo alguna archivo alguna linea que tu tocaste
wow esto fue increíblemente claro y directo. Muchas gracias!
Mas claro ni el agua, muchas gracias amigo!
claro y sencillo 👍
Por fiiiiiin me he enteradoooooo
Eureka!!!!😂😂😂😂
Muy buen video, esta explicación es la mejor que ví. Gracias
Excelente, claro, conciso y al punto. Muchas gracias!
Buenos días, muy buen video. Solo que por mi parte veo que no se respondió lo que pregunta en el título, si se ven los dos casos de merge y rebase, pero no se responde a la pregunta ¿Cuándo usar cuál?.
Todavía me queda la duda de en qué casos es conveniente usar merge y en qué casos es conveniente usar rebase.
Gracias.
Yo creo que queda muy claro. Depende de lo que quieras hacer. En primer lugar jamás uses rebase en ramas que son públicas ( las que has hecho push). Luego usa rebase si quieres guardar todo tu historial de commits o usa merge si no quieres guardar el historial de commits, solo los cambios. En rebase ves cada uno de los commits, en merge tienes los mismos cambios pero fusionados en un solo commit. Por seguridad, si tienes dudas, usa siempre merge.
Muchísimo mejor explicado que el video del curso. Muchas gracias, nuevo sub
Gracias a ti Juan!
Excelente explicación amigo
Súper la explicación!
Buena explicación, gracias.
Muy bueno, lo entendí. Gracias 👍
ufff muchas gracias me haz salvado
Amazing explanation, thanks for sharing.
Thanks a lot Carlos, your welcome!
Brutal, sería genial ver uno sobre git stash
Saludos Javier, no había respondido a tu comentario por que estaba preparando este video que me pediste, ojalá te guste: th-cam.com/video/nqTIbGCzNVk/w-d-xo.html
muy claro, me gustó
Muy buena explicación. Gracias
gracias por el aporte
De nada!, gracias por comentar
Excelente explicación.
excelente video, una pregunta, cuál es la herramienta que usas para mostrar las ramas de git a la derecha?
X2
¿Osea que son lo mismo pero uno deja la linea de lo que se venia haciendo (merge) y el otro la borra y lo integra en tu rama (rebase)?
Ahora que ya lo entendí, la pregunta es: cuando conviene usar cada uno
Otra preguntica, pongo el comentario a parte para no mezclar los temas. Es que me llamó mucho la atención el comando reset --hard, para ir a un commit anterior.
Teniendo las ramas de esta forma:
feature = id_commit1, id_commit2, id_commit3
develop = id_commit1, id_commit2, id_commit3, id_commit4, id_commit5
La rama feature es mi local y la de develop es en donde se trabaja colaborativamente con otros desarrolladores, dicho esto, id commit 4 y id commit 5 lo han subido otros.
Si yo le doy en mi rama feature un reset --hard hacía commit1 y le hago push a la rama de develop. La pregunta es ¿Qué queda en la rama de develop?
Tratando de responder a mi pregunta, ¿Quedaría de esta forma al hacer el push de feature a develop?
feature = id_commit1
develop = id_commit1, id_commit4, id_commit5
Gracias
Hola que tal, argadeciendo por el aporte, creo que es el primer video que me topo con tu canal y ya me suscribi
haber si entendi bien:
Entonces Meramente es solo para "mantener" el historico de los commit, cierto?, es decir:
Con Merge: podras ver la historia de los commit que se hicieron en un branch o mas bien dicho su "traza" (usando graph), observando como se bifurca o se parte en que punto de la historia y cuando se "integra", generando un nuevo branch o punto para unir ambos cambios.
Con Rebase: es hacer un historico "mas limpio" respecto a que si se visualiza su historico (usando graph), solo veriamos una "traza", es decir , como si todos los cambios que hicimos, los hicieramos directos en master (o en el repo donde se haga el rebase), pero no sabriamos asi tan facilmente que fue lo que paso o a partir de que punto se inicio el cambio y al final cuando se quiera unir ambos codigos/cambios (usando rebase posicionandonos desde la rama que queremos unir) se tendra que hacer un merge "manual" para que se integren los cambios, tomando como el ultimo Commit el del ultimo generado en la rama que se hizo rebase (por que se uso fast-forward),
se uso el merge fast-forwad- o mas bien dicho , Git uso sin nuestro consentimiento el fast-forward por que implicitamente detecta que se uso un rebase y merge?, es decir es opcional que use fast-forwad o eso puede cambiar (aun nose para que pero ,ver la posibilidad y que se haria o por que hacerlo distinto)
Una duda, mas :) , aun tengo la mala practica o costumbre de realizar un backup del repositorio y del codigo que quiero integar en alguna ruta de la pc,
despues lo que hago, es copiar y pegar algunos archivos (los que son nuevos)
y los archivos que se que tienen cambios los comparo (con winmerge o algun otro comparador) manualmente y hago los cambios, y en git solo doy "git add" y "git commit".
Sin embargo quiero irle perdiendo el miedo y practicar para evitar hacer esas comparaciones y modificaciones manuales, y hacerlo con git, nose si solamente sea posible ir verificando con "git diff" y haciendo los merge o rebase, o como podria hacerlo, alguna herramienta con git para abrir el comparador y elegir que lineas de codigo dejar o quitar?
PD: perdon por la carta :)
Temo decirte que no … el merge ni es solo coger los commits es fusionar lo que hiciste en esa rama aparte…
Una pregunta:
La herramienta gráfica de la derecha es automática?
Qué herramienta es?
X2
¡Qué pena que no siguieras con los videos de los patrones o con más ejemplos de ello y de lo relativo a SOLID!
Saludos Pedro, la serie de patrones de diseño va a continuar, el video que estoy preparando es el de cadena de responsabilidad. Tenía mucho tiempo sin subir video y este tema me gusto. Espero en unos días poder subir otro de patrones, en el inter comenzaré a subir videos de diferentes herramientas.
Buen vídeo!
Muchas gracias Jhoan!
para que sirven esos pogramas?
Excelente vídeo, mi pregunta es su de alguna forma se puede configurar para que muestre el commit con la nota del merge, así uno lo tiene mas claro, o forzar a realizar un merge sin el fast-forward
¿Cómo podrías crear una rama a partir de otras 2 ramas?
Vale decir crear una tercera rama que contenga los commits de una primera rama y una segunda rama
seria genial que hagas un zoom?, no veo bien porque soy miope
Gracias a vos lo entendi! Pero una consulta, que diferencia hay entre git rebase y git pull --rebase? Lo he buscado pero no lo entiendo.
Me suscribi a tu canal
Saludos bro, el pull lo que hace es descargar los cambios del repositorio remoto, y con las banderas --rebase o --merge, es la estrategia que usará git para fusionar los cambios, espero esto te sirva. Saludos!
Muchas gracias por el video, me fue de gran ayuda!! Una pequeña consulta, cómo se llama la app que usabas a la derecha donde se iba viendo los commit y ramas creadas?
Gracias a ti Luis por ver el video, la app se llama GitUp (github.com/git-up/GitUp) no solo sirve para visualizar el repositorio en modo gráfico, tiene muchas otras funciones. Saludos!
@ No hay niguno igual que gitup para windows
???
nice bro
gracias, saludos!
se ve bueno el video, pero no es muy real este tipo de situaciones... Por lo general siempre se tiene una rama master, una develop y una feature donde se trabajara , esta rama feature se obtiene siempre de develop. Los problemas que suceden son que alguien actualizo develop , y cuando quieres pasar tus cambios a develop entonces tienes problemas con MERGE si alguien actualizo alguna archivo alguna linea que tu tocaste
Excelente video
Una pregunta:
Como se llama el programa que estás utilizando al lado derecho
Se llama GitUp, lo encuentras aquí github.com/git-up/GitUp
buen esfuerzo, gracias por el video, pero no es tan simple no entendí.
creo que no saber responder esto me hizo perder la oportunidad de mi vida, en fin