dudas flujo de trabajo

[Sergio Cubero Torres]

Hola. Soy nuevo en el uso de control de versiones y no entiendo bien la logica del flujo de trabajo. Todo lo q leo esta orientado a tener una copia local para desarrollar y subir los cambios a produccion. Pero no siempre es posible ya q replicar en una maquina local el sistema de produccion no es posible. Por eso suelo trabajar con 2 servers. Produccion y desarrollo identicos, salvo en la bases de datos. Mi flujo es hacer los cambios en el server de desarrollo y una vez acabados hacer diff con el server de produccion. ¿cual es la mejor manera de trbajar asi con git?
Mis desarrollos son orientados a la web.
Gracias

[Mariano Garcia Berrotarán]

Hola!

Se me ocurren 3 formas diferentes que podes hacer esto!:

1 - El Bueno:

Si es raro que cambies tus archivos de configuracion, le podes decir a git que ignore los cambios para ese archivo, haciendo

$ git update-index --assume-unchanged path/a/archivo

y git te va a dejar de reportar los cambios a ese archivo. no va a aparecer en git diff o git status.

Cuando quieras volver a trackear ese archivo, haces:

$ git update-index --no-assume-unchanged path/a/archivo

y lo vas a ver los cambios que le hagas a ese archivo.

2 - El Malo:

Podes agarrar tu working directory limpio, editar tu archivo de configuracion y hacer un stash:

$ git stash
Saved working directory and index state WIP on master: 26709e3 asd
HEAD is now at 26709e3 asd

haces todos los cambios y commits que quieras hacer. Despues podes aplicar ese stash haciendo

$ git stash apply

y vas a tener de vuelta los cambios que salvaste antes, en tu working directory. Con este método capaz que lo que termina pasando es que terminas guardando cosas en el stash que pretendias commitear, o terminas haciendo commit de los cambios en tus configuraciones, cosa que no querias (sobre todo si usas git commit -a indiscriminadamente como yo). Aparte preparate para hacer merges si cambias ese archivo de configuracion antes de hacer el apply!

3 - El Feo

Otra que se me ocurre es que uses un branch con tu configuracion, mientras que en master mantenes la config del server. Independientemente de donde haces los cambios, siempre haces un merge a tu branch local, y probas ahí. capaz es tan frustrante como la opcion anterior.

[Tordek]

On Wed 21 May 2014 18:49:34 ART, Mariano Garcia Berrotarán wrote:
> Hola!
>
> Se me ocurren 3 formas diferentes que podes hacer esto!:

Si lo único que querés mantener separado es la config, yo te diría que
tengas

config-example.foo
config.foo
.gitignore << config.foo

Cuando copiás el repo a una máquina, creás el config.foo relevante,
pero no lo metés en VC.

También hay una recomendación que te dice que las configuraciones de
ese estilo (es decir: DBs, etc) se pasan por ENV [0].

Y hay cosas para mencionar con meter tu DEV en una VM Vagrant, así
podés replicar aún más similar al env de PROD... aunque nunca lo hice,
así que no sé qué tanto lio es.

[0] http://12factor.net/config

--
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek

[Juan Manuel Santos]

No se si entendí bien la pregunta pero no veo por qué no se puede usar git en
este caso. Ya en otros correos te contestaron lo del config (referido estimo a
los datos de la DB).

El resto de la jodita lo podés hacer con un repo local que tenga 2 remotes:
producción y dev. Cada remote va a apuntar a un repo en el servidor homónimo,
y en base a el estado de tus commits locales, podés pushear a dev o a prod.
Alternativamente, si siempre sí o sí vas a pasar por dev, podés dividirlo así:

repo prod en máquina prod ---> repo dev en máquina dev ----> repo local en tu
máquina

Vos siempre vas a estar pusheando entonces a dev, y cuando necesites pushear a
prod, lo hacés desde dev.

Saludos
--
Juan Manuel Santos <vicar...@gmail.com>
Pubkey: www.vicarious.com.ar/~godlike/godlike64.at.gmail.dot.com.asc

[Sergio Cubero Torres]

Hola.

La idea de disponer del deploy con vagrant en muy buena idea para esto y para casi todo.

Pero no me queria meter con  vagrant por  ahora.  

Gracias.

[Sergio Cubero Torres]

Hola.

Voy a aplicar el primer método a ver que tal me va.

La idea que me queda entonces es:

En una maquina de desarrollo tengo el apache, y creo un repositorio dentro del /var/www/ donde vaya a trabajar.

Una vez tenga cambios para comit los subo a un segundo repositorio remoto (el master). y desde allí hacer una configuración del un hook post-receive, el cual actualiza los ficheros en el server de producción cuando realice un push.

Tal y como se describe aquí; http://toroid.org/ams/git-website-howto


Mi intención inicial era que en el mismo /var/www tener los ficheros de producción junto con el repositorio, para no tener que hacer tanto movimiento de ficheros entre carpetas (repositorios), pero aprendiendo un poco más me he dado cuenta que eso no se puede hacer por lo menos en produccion (si en desarrollo) ya que cuando cambias de rama cambias los contenidos de la carpeta/ficheros.

Saludos y gracias por la ayuda.