Estimado, el diagrama y la explicación esta incompleta, falta indicar que hotfix también se tiene que fusionar con develop luego de la corrección, sino esa corrección se perderá cuando se hagan futuras fusiones desde develop, ya que no contendrá esa corrección.
No se debería perder, porque al hacer el PR de develop a master primero se deben sincronizar ambas ramas y como los cambios de hotfix ya estan en master se los traería. Es como decir que los cambios que yo haga en una rama a parte deben ir tanto a master como a todas las ramas que haya credo el equipo, no tiene sentido
@@DajuSarNo puedes hacer PR de develop a Master, eso sería arriesgado e irresponsable, estarías pasando funcionalidades que tienes en Develop pero que aún no han sido validadas y ajustadas en la rama Release. Tienes que hacer PR de Release hacia Master siempre. Luego una vez fusionadas las funcionalidades en Master haces la fusion de Release a Develop y es eso lo que te plantea @jara5150 . Por otro lado yo en mi equipo de trabajo manejamos una poco distinto este ajuste, detectamos que hay una perdida de commits al hacerlo de forma oficial de Gitflow ya que aunque fusiones de Release a Develop se pierde el "commit de fusion" de Release a Master, por tanto cuando fusionamos en Master, tambien hacemos la fusión de Master a Develop, así se sincronizan todos los Commits sin perdida en la trazabilidad a través de los commits de fusión (merge commits) que te deja Git.
Muy buen video, super claro y buen audio. Al principio es un poco confuso que no mencionas la rama Hotfix, aunque la mencionas al final, pero al principio parece que te la has brincado. Ok repito, muy buen video.
muy claro!
Estimado, el diagrama y la explicación esta incompleta, falta indicar que hotfix también se tiene que fusionar con develop luego de la corrección, sino esa corrección se perderá cuando se hagan futuras fusiones desde develop, ya que no contendrá esa corrección.
No se debería perder, porque al hacer el PR de develop a master primero se deben sincronizar ambas ramas y como los cambios de hotfix ya estan en master se los traería. Es como decir que los cambios que yo haga en una rama a parte deben ir tanto a master como a todas las ramas que haya credo el equipo, no tiene sentido
no faltó la explicación del Hotfix, sólo que la dejó para el final. Si es un poco confuso, pero la información si está en el video.
@@DajuSarNo puedes hacer PR de develop a Master, eso sería arriesgado e irresponsable, estarías pasando funcionalidades que tienes en Develop pero que aún no han sido validadas y ajustadas en la rama Release. Tienes que hacer PR de Release hacia Master siempre. Luego una vez fusionadas las funcionalidades en Master haces la fusion de Release a Develop y es eso lo que te plantea @jara5150 . Por otro lado yo en mi equipo de trabajo manejamos una poco distinto este ajuste, detectamos que hay una perdida de commits al hacerlo de forma oficial de Gitflow ya que aunque fusiones de Release a Develop se pierde el "commit de fusion" de Release a Master, por tanto cuando fusionamos en Master, tambien hacemos la fusión de Master a Develop, así se sincronizan todos los Commits sin perdida en la trazabilidad a través de los commits de fusión (merge commits) que te deja Git.
Etuvo muy buena tu explicacion, queria saber en que programa haces esos diagramas con los que explicaste el flujo, gracias
Muy buen video, super claro y buen audio. Al principio es un poco confuso que no mencionas la rama Hotfix, aunque la mencionas al final, pero al principio parece que te la has brincado. Ok repito, muy buen video.
Se suele tener un ambiente de pruebas, que brinda una URL donde se puede validar, con este flow cuantos ambientes con URL tendriamos?
Deberían ser 3 ambientes, uno para dev otro para release que comúnmente llamamos test o staging y uno para prod.