Si tienes dudas o preguntas, recuerda que también puedes preguntarle a nuestra hermosa comunidad a través del Discord oficial de este servidor. Únete visitando discord.makigas.es.
Muy bien explicado, pues la verdad yo personalmente prefiero utilizar 'merge' que 'rebase' ya que me gusta dejar un buen historial de como estoy trabajando y de lo que se hizo. Pero como dices muy bien en el vídeo depende de la situación y de como este trabajando el equipo. ¡Felicidades makigas! muy buenos vídeos, espero seguir viendo vídeos tuyos.
Así existan mil commits en una simple feat? he visto ramas con commit como "solved comments pr" y así... en estos casos no meparece completamente necesario tener esa trasabilidad.
Muchas gracias crack!!, llevo meses huyendo del rebase y por fin contigo lo he entendido y he podido aplicarlo...tan sencillo y me costó algun disgusto que otro!!!
Gracias compañero! Este tema la verdad no lo entendi nada en el libro de Pro Git y solo con ver este tutorial conciso y al grano lo entendi perfectamente! He estado con otros dos videotutoriales que no entendi nada y que parecian mas tutoriales de como hacer un expresso que de Git. Muchas gracias y nuevo sub!
Genial la serie. A pesar de haber pasado ya un tiempo, me ha sido de gran utilidad todos y cada uno de los capitulos ;) Enhorabuena, y sigue asi, crack!!
Bueno. El uso o no de bifurcaciones visibles en el historial depende del caso, de cada quien y del equipo. Por mi parte si trabajo en ramas diferentes para desarrollar una nueva característica bien especificada es mejor dejar la bifurcación en el histórico, pero si es una separación sólo por seguridad tal vez no. Para trabajar con más personas sin duda es mejor hacer un merge declarado, ya que el resto sabrá específicamente cuándo se ha hecho un fix o una nueva característica. Así se puede ver mejor la familia de modificaciones y sería posible incluso deshacer el conjunto de commits que significaban un mismo cambio con mayor claridad. Aunque dependerá de la arquitectura con la que trabaje dicho equipo. Así como existe Git Flow y es la alternativa para muchos, no aplica para las recomendaciones de desarrollo de software libre de GitHub. A muchos no les gustará ver otras ramas diferentes a master. Afortunadamente existe la libertad de escoger lo que nos convenga según el caso.
que opinan de hacer merge para features branches al integrar a develop y releases y utilizar merge --squash para pasar a master, así mantener en master un historial limpio?
Hola! muy bien explicado casi todo menos este capitulo que sinceramente me cuesta seguir el ejemplo. Para un nivel principiante es confuso que se explique de manera tan rapida! me cuesta seguirte en este video! hasta acá venia bastante bien. que es lo del touch? eso no lo habiamos visto antes. Sería muy bueno tener mas soporte visual para entender. muchas gracias exelente el curso!
Personalmente me agrego al merge pero hay de casos a casos no..., como aporte despues de pushear y hacer un commit --amend para añadir unas cosillas y luego en remoto, tambien es una pesadilla creando commit a lo loco, se puede hacer un reset --soft local y luego un push origin -f y listo. Para no dejar commit por doquier que nos averguencen. jejej.
Es cuando hacemos un merge y este se ejecuta mediante la estrategia de fast forward (avance rápido), sin necesidad de usar ninguna estrategia recursiva. Osea cuando solo hubo cambios en una rama y no en la otra.
Estaria bueno un tutorial mas amplio sobre GitRebase. Saludos.
4 ปีที่แล้ว +1
En mi opinión en merge es mas para una directiva rigurosa que desea ver las ramas y sus puntos de función por otro lado el rebase es mas bien cuando todos son expertos conocidos y confían los unos a los otros en que el código estriara bien escrito. Para mi el rebase puede ser para uso personal para uso corporativo deberíamos dejar el historial con todos sus detalles, isa monitorear quien hace el trabajo y quien no lo hace. Prefiero el merge por ahora ya que soy novato y deseo ver y navegar por los commit y segur sacando e incorporando ramas.
prefiero merge! Buen video. Consulta, habrá algún programa UI, que me permita hacer merge con el local, de manera visual ?. Claro, para una mayor cantidad de conflictos.
Ramas develop, calidad y master. cada con su respectiva url de revision. Desarrollador # 1 trabaja unas lineas de código y sube a la rama develop, pero aun sigue haciendo código y funcionalidades varias y sigue subiendo a develop mientras trabaja y para ir mostrándole a la persona QA. Por otro lado el desarrollador # 2, también hace otras funcionalidades y también se va subiendo a la rama develop para que se vaya revisando en develop también. 6. EL punto crucial es que llega el momento en que el Jefe le dice al desarrollador # 2 que pase todo lo que este hizo y suba a calidad y a master, pero sucede que al pasar (merge) a calidad y luego a master se estaría pasando todo el (codigo de Desarrollador #1 y código del Desarrollador #2) y sólo se necesita pasar (merge o pull-request) del código del Desarrollador #2. Pregunta: Cómo hacemos para hacer Merge o pull-request de SOLO el código subido a develop del Desarrollador #2 y pasarlo a calidad y luego esto mismo a master. Gracias.
Porque lo ideal si van a trabajar por partes en varios commits es que mientras no hayan terminado su tarea actual Desarrollador #1 y Desarrollador #2 trabajen en ramas distintas y sólo mezclen a develop cuando hayan terminado. Así cada uno tiene su propia rama independiente, que puede ser compartida con otras personas mediante pull y que puede ser mezclada cuando interese. En Git crear y destruir ramas es barato, a diferencia de CVS o SVN; cuantas más se hagan mejor, ya habrá tiempo de ir borrándolas cuando se haya mezclado en develop, calidad o master.
Me gusta el rebase, y adicional a eso, me gusta llamar las ramas asi "feature/1234_xxx" donde 1234 es el numero de la tarea. Y adicional, los mensajes de los commits asi: "[#1234] mensaje". Saludos
Si tienes dudas o preguntas, recuerda que también puedes preguntarle a nuestra hermosa comunidad a través del Discord oficial de este servidor. Únete visitando discord.makigas.es.
Hermano hola. 2 años despues de tus videos no sabes lo mucho que hoy me estan ayudando. no sabes lo mucho que haces con esto. gracias gracias gracias
nueve años de estos videos y todavia siguen siendo muy utiles gracias @makigas
Muy bien explicado, pues la verdad yo personalmente prefiero utilizar 'merge' que 'rebase' ya que me gusta dejar un buen historial de como estoy trabajando y de lo que se hizo. Pero como dices muy bien en el vídeo depende de la situación y de como este trabajando el equipo.
¡Felicidades makigas! muy buenos vídeos, espero seguir viendo vídeos tuyos.
Así existan mil commits en una simple feat? he visto ramas con commit como "solved comments pr" y así... en estos casos no meparece completamente necesario tener esa trasabilidad.
Muy buen tutorial, lo estoy viendo desde el principio. Muy buena camiseta. Saludos desde Argentina!!!
¡Gracias!
Muchas gracias crack!!, llevo meses huyendo del rebase y por fin contigo lo he entendido y he podido aplicarlo...tan sencillo y me costó algun disgusto que otro!!!
Gracias compañero! Este tema la verdad no lo entendi nada en el libro de Pro Git y solo con ver este tutorial conciso y al grano lo entendi perfectamente! He estado con otros dos videotutoriales que no entendi nada y que parecian mas tutoriales de como hacer un expresso que de Git. Muchas gracias y nuevo sub!
Increíble que no hubiera encontrado este canal antes. Muchas gracias.
Excelente video, gracias por compartirnos este excelente tutorial, saludos desde Gdl, México !
Genial la serie. A pesar de haber pasado ya un tiempo, me ha sido de gran utilidad todos y cada uno de los capitulos ;) Enhorabuena, y sigue asi, crack!!
Recién ahora me doy cuenta de la remera que llevabas ese día XD
Que buen curso, :) gracias por los tutoriales
Gracias groso! Genial video
Buen video, pero sobre todo buena casaca. Vamos Argentina!
Argentina papaaaaaa
Aún sigo teniendo esa camiseta aunque hayan pasado los años :)
¡Hostias! es el makigas peludo
Buenisimo, un abrazo y gracias.
Bueno. El uso o no de bifurcaciones visibles en el historial depende del caso, de cada quien y del equipo.
Por mi parte si trabajo en ramas diferentes para desarrollar una nueva característica bien especificada es mejor dejar la bifurcación en el histórico, pero si es una separación sólo por seguridad tal vez no.
Para trabajar con más personas sin duda es mejor hacer un merge declarado, ya que el resto sabrá específicamente cuándo se ha hecho un fix o una nueva característica. Así se puede ver mejor la familia de modificaciones y sería posible incluso deshacer el conjunto de commits que significaban un mismo cambio con mayor claridad.
Aunque dependerá de la arquitectura con la que trabaje dicho equipo. Así como existe Git Flow y es la alternativa para muchos, no aplica para las recomendaciones de desarrollo de software libre de GitHub. A muchos no les gustará ver otras ramas diferentes a master.
Afortunadamente existe la libertad de escoger lo que nos convenga según el caso.
Vine por git, me quede por la camiseta ❤
prefiero que se vea el log con todas las ramas ! saludos, muy bueno el tuto.
que opinan de hacer merge para features branches al integrar a develop y releases y utilizar merge --squash para pasar a master, así mantener en master un historial limpio?
Hola! muy bien explicado casi todo menos este capitulo que sinceramente me cuesta seguir el ejemplo. Para un nivel principiante es confuso que se explique de manera tan rapida! me cuesta seguirte en este video! hasta acá venia bastante bien. que es lo del touch? eso no lo habiamos visto antes. Sería muy bueno tener mas soporte visual para entender. muchas gracias exelente el curso!
Yo siempre la cago cuando uso git rebase.
Veamos si después de este video dejo de cagarla xD
Dejar de cagarla es dificil, pero si seguramente la cagaras un poquito menos...jajajaja!!!!!
Tranquilo que no sos el único q la caga 😆🤷🏻♂️
Esto fué hace tres años, ¿finalmente dejaste de ca-garla? XD
Muy bien explicado, me gusta mucho git rebase. Sin embargo, es muy propenso a errores. En mis equipos por lo general tratamos de evitarlos.
Personalmente me agrego al merge pero hay de casos a casos no..., como aporte despues de pushear y hacer un commit --amend para añadir unas cosillas y luego en remoto, tambien es una pesadilla creando commit a lo loco, se puede hacer un reset --soft local y luego un push origin -f y listo. Para no dejar commit por doquier que nos averguencen. jejej.
Sí, lo de esconder los commits avergorzantes es un mundo plagado de estrategias :)
Por q dices al final que no hay q hacerlo con commits pusheados?
Hola buenas tardes, podrías explicar el concepto de fast forward? Y si hay que evitarlo? Gracias
Es cuando hacemos un merge y este se ejecuta mediante la estrategia de fast forward (avance rápido), sin necesidad de usar ninguna estrategia recursiva. Osea cuando solo hubo cambios en una rama y no en la otra.
thx
Estaria bueno un tutorial mas amplio sobre GitRebase. Saludos.
En mi opinión en merge es mas para una directiva rigurosa que desea ver las ramas y sus puntos de función por otro lado el rebase es mas bien cuando todos son expertos conocidos y confían los unos a los otros en que el código estriara bien escrito. Para mi el rebase puede ser para uso personal para uso corporativo deberíamos dejar el historial con todos sus detalles, isa monitorear quien hace el trabajo y quien no lo hace. Prefiero el merge por ahora ya que soy novato y deseo ver y navegar por los commit y segur sacando e incorporando ramas.
para mi sinceramente el merge para saber pero el que manda siempre es el que maneja el proyecto gracias
como deshacer un git rebase ?
prefiero merge!
Buen video.
Consulta, habrá algún programa UI, que me permita hacer merge con el local, de manera visual ?. Claro, para una mayor cantidad de conflictos.
Hola, te recomiendo que pruebes gitkraken para linux o sourcetree si usas macOS/windows, son los mejore en mi opinión. Saludos
gracias, voy a revisarlo!
Ramas develop, calidad y master. cada con su respectiva url de revision.
Desarrollador # 1 trabaja unas lineas de código y sube a la rama develop, pero aun sigue haciendo código y funcionalidades varias y sigue subiendo a develop mientras trabaja y para ir mostrándole a la persona QA.
Por otro lado el desarrollador # 2, también hace otras funcionalidades y también se va subiendo a la rama develop para que se vaya revisando en develop también.
6. EL punto crucial es que llega el momento en que el Jefe le dice al desarrollador # 2 que pase todo lo que este hizo y suba a calidad y a master, pero sucede que al pasar (merge) a calidad y luego a master se estaría pasando todo el (codigo de Desarrollador #1 y código del Desarrollador #2) y sólo se necesita pasar (merge o pull-request) del código del Desarrollador #2.
Pregunta: Cómo hacemos para hacer Merge o pull-request de SOLO el código subido a develop del Desarrollador #2 y pasarlo a calidad y luego esto mismo a master. Gracias.
Porque lo ideal si van a trabajar por partes en varios commits es que mientras no hayan terminado su tarea actual Desarrollador #1 y Desarrollador #2 trabajen en ramas distintas y sólo mezclen a develop cuando hayan terminado. Así cada uno tiene su propia rama independiente, que puede ser compartida con otras personas mediante pull y que puede ser mezclada cuando interese. En Git crear y destruir ramas es barato, a diferencia de CVS o SVN; cuantas más se hagan mejor, ya habrá tiempo de ir borrándolas cuando se haya mezclado en develop, calidad o master.
+makigas Okay. rtrabajar en ramas diferetes cada uno y cuando se necesite, ahí sí se sube a la develop.
Gracias.
Porque escribes "git lod " que es "lod" ????
(3:25)
Hola. Lo menciono en el episodio 13 dedicado a alias, es un alias que me fabriqué que equivale a "log --decorate --oneline"
Me gusta el rebase, y adicional a eso, me gusta llamar las ramas asi "feature/1234_xxx" donde 1234 es el numero de la tarea. Y adicional, los mensajes de los commits asi: "[#1234] mensaje". Saludos
Que viva el merge y los 200 comits del pánico jeje.
Rebase es mi pesadilla, pero es cuestion de usarle.
Gracias por el vídeo, prefiero una historia lineal limpia...
Y esa remera de la AFA? :O :O :O
Heh.. ;)
ostias! no estabas calvo aqui xD haha sorry
prueba git worktree a ver que tal
me mareaste
Malisimo tutoral de quinta