Potenciales conflictos sobre builds, git pushes y otros cuando se sobreponen en un proyecto...

En general, al hacer un push en GitHub se intentará subir todos los cambios realizados en los archivos locales al repositorio remoto. Si se han hecho cambios en un módulo o componente que necesita un build para desplegarse correctamente, es posible que esos cambios no tengan el efecto deseado si no se ha construido el proyecto.

Por lo tanto, para asegurarse de que los cambios se reflejen correctamente, es recomendable seguir los siguientes pasos:

1. Realizar el build del proyecto localmente.
2. Probar los cambios en el proyecto construido y verificar que están funcionando correctamente.
3. Hacer un `add`, `commit` y `push` en ese orden para subir los cambios al repositorio remoto.

De esta forma, se asegura que los cambios estarán disponibles en el repositorio remoto y que funcionarán correctamente cuando se implementen. Si se hace el `add`, `commit` y `push` sin haber construido el proyecto, es posible que se suban cambios que no funcionen como se espera.

Pues hay 2 opciones:

1. Hacer la build fijándola a un commit en lugar de a un branch.
2. Tienes un branch distinto.

Es muy normal siempre trabajar en branch distintos incluso cuando desarrollas solo. Por ej. yo hace poco saqué el Multipaste 3.0, pero durante todo el desarrollo de eso, estuve en otro branch y recién al lanzar la versión 3.0 ese branch se pasó a master.

Por otro lado, muchas veces tengo clientes que quieren modificaciones específicas para ellos en los códigos que hago, pero como luego cuando hayan actualizaciones igual querrán esos cambios otra vez junto con las actualizaciones. Lo que hago es poner su versión modificada en un branch y lo dejo ahí, luego cuando haya updates y el cliente me pida que le de las actualizaciones, pero con sus cambios, se hace un upstream update a ese branch.

kj

kj2 dijo:

Pues hay 2 opciones:

1. Hacer la build fijándola a un commit en lugar de a un branch.
2. Tienes un branch distinto.

Es muy normal siempre trabajar en branch distintos incluso cuando desarrollas solo. Por ej. yo hace poco saqué el Multipaste 3.0, pero durante todo el desarrollo de eso, estuve en otro branch y recién al lanzar la versión 3.0 ese branch se pasó a master.

Por otro lado, muchas veces tengo clientes que quieren modificaciones específicas para ellos en los códigos que hago, pero como luego cuando hayan actualizaciones igual querrán esos cambios otra vez junto con las actualizaciones. Lo que hago es poner su versión modificada en un branch y lo dejo ahí, luego cuando haya updates y el cliente me pida que le de las actualizaciones, pero con sus cambios, se hace un upstream update a ese branch.

kj

Hacer clic para expandir...

Me diste una idea y lo que pones es muy acertado e ingenioso. Me cuesta aún dominar las branches, abrirlas y luego fusionarlas, pero es momento de tratar de mejorar el manejo de esa herramienta... Gracias!

kj2 dijo:

Pues hay 2 opciones:

1. Hacer la build fijándola a un commit en lugar de a un branch.
2. Tienes un branch distinto.

Es muy normal siempre trabajar en branch distintos incluso cuando desarrollas solo. Por ej. yo hace poco saqué el Multipaste 3.0, pero durante todo el desarrollo de eso, estuve en otro branch y recién al lanzar la versión 3.0 ese branch se pasó a master.

Por otro lado, muchas veces tengo clientes que quieren modificaciones específicas para ellos en los códigos que hago, pero como luego cuando hayan actualizaciones igual querrán esos cambios otra vez junto con las actualizaciones. Lo que hago es poner su versión modificada en un branch y lo dejo ahí, luego cuando haya updates y el cliente me pida que le de las actualizaciones, pero con sus cambios, se hace un upstream update a ese branch.

kj

Hacer clic para expandir...

Parece que sabes mucho del tema. Es un poc diferente el ejemplo porque no es fácil de explicar o no lo hice bien. Lo resolví así, en cada repositorio hijo entro, hago git add . y git commit -m, y luego hago lo mismo en el repositorio padre. Así dejó de presentar conflictos, eso hasta que aprenda a manejar Docker...

Creo que yo si te entendí y según mi xp solo pusheas los cambios, lo que ya estaba se queda como estaba aunque hagas add . En el padre.

Benderslab dijo:

Creo que yo si te entendí y según mi xp solo pusheas los cambios, lo que ya estaba se queda como estaba aunque hagas add . En el padre.

Hacer clic para expandir...

En el caso que me funciona luego de 'adear' y 'comitear' cada uno antes que el padre, permite el push; si no comiteo los individuales antes no me permite hacer push. AL final las subinstalaciones son como módulos...

ultracobra dijo:

En el caso que me funciona luego de 'adear' y 'comitear' cada uno antes que el padre, permite el push; si no comiteo los individuales antes no me permite hacer push. AL final las subinstalaciones son como módulos...

Hacer clic para expandir...

Intenta commiteando los hijos y luego haz add . Y push en el padre