Desarrollo y producción de GIt Workflow: ¿dónde debo crear los repositorios?

Question

Leí en alguna parte* que una configuración como esta sería buena:

Dos ramas principales, una para cada servidor.

Empujar hacia el dominio envía los cambios a la vida;

Empujar a dev/stage (o como lo llames) envía cambios a la puesta en escena;

Flujo de trabajo:

• Crear rama desde dev;

• trabaje localmente hasta que esté listo para realizar la prueba;

• fusionarse nuevamente con el desarrollador;

• push to Hub, que envía los cambios al servidor de desarrollo/ensayo.

Una vez que esté listo con ellos para publicarlos:

• fusionar de desarrollador a maestro,

• luego envíe master al Hub, que envía esos cambios al servidor en vivo.

Dos ramas principales, una para cada servidor.

Así que tengo una rama "Producción" en "Webroot/MyLiveApp/" y otra rama "Desarrollo" en "Webroot/DevApp/"

¿Dónde debería estar el repositorio?

ACTUALIZAR:

Quiero decir:

Tendremos, según este flujo:

• Repositorio principal;

• Centro de repositorios desnudo;

• Clones;

Las ramas de desarrollo y producción deberían pertenecer a un repositorio, ¿verdad?

Si esto es correcto, ¿dónde deberíamos emitir el PRIMER comando git init?¿En nuestro repositorio Prime?

Entonces tendremos:

"webroot/myliveapp/" - rama de producción;

"webroot/devapp/" - rama de desarrollo;

"webroot/.git" - Repositorio principal;

Esto tiene sentido ?

¿O el repositorio Prime debería corresponder a la ubicación de nuestra sucursal de producción?

*Nota:Si necesita un contexto sobre qué flujo de trabajo estoy intentando implementar, es este:http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Gracias por la actualización de tu pregunta, ahora está más claro.

Creo que el problema que tienes se basa en una mala comprensión del flujo de trabajo de Git;Git no equivale directorios a las ramas, equivale a vista de su sistema de archivos a sucursales.Esto es poderoso, pero es fácil dispararse en el pie.Dejame explicar.

Git actúa más como un sistema de archivos de seguimiento del historial, con versiones diferenciales y respaldado por una base de datos.Está "por encima" de su sistema de archivos, no "parte de" él.No utiliza su sistema de archivos para representar ramas, sino que, cuando revisa una rama diferente, todos los archivos en su sistema de archivos cambiarán para ser los archivos en esa rama.Le estás pidiendo a Git que haga que tu sistema de archivos represente la realidad alternativa de esa rama.

Si estas en sucursal master, y tiene un archivo root/foo.txt comprometido, y revisas la sucursal experiment, que hace no tener root/foo.txt comprometido, encontrará ese archivo desaparecido cuando lo buscas.es parte de master, no experiment, por lo que no está presente en su sistema de archivos.Esta es la razón por la que Git es muy exigente a la hora de confirmar su rama actual antes de permitirle cambiar de rama: si tiene cambios no realizados en su sistema de archivos que Git no conoce, se niega a eliminarlos sobrescribiéndolos con una realidad diferente.Primero tienes que intervenir para arreglar las cosas.

Entonces, para responder la pregunta, no cree subdirectorios para "myliveapp" y "devapp", cree diferentes sucursales.Simplemente tenga su única base de código en "webroot".Luego, elimine, digamos, la rama "inestable", realizando los cambios como de costumbre.Luego puede cambiar todos los archivos en su repositorio para que estén en la versión de los archivos de su servidor de desarrollo cambiando a la rama "devapp", y de manera similar puede volver a "inestable" en cualquier momento.

Cuando desee actualizar una sucursal, p.Al realizar una actualización de su servidor de desarrollo, puede merge "inestable" en "devapp".Esto hará que todos los archivos de "devapp" se vean como los de "inestable", actualizándolo.

Otra cosa a tener en cuenta:la diferencia entre un repositorio principal, un repositorio básico y clones es casi nula.Prácticamente no hay diferencia en el software;más bien, es una convención humana decir "el kernel de Linus es el kernel canónico de Linux".Con ese entendimiento:

• Un repositorio principal es solo un repositorio que todos coinciden en que contiene la versión "canónica" del software.Es decir, cada vez que un desarrollador ha hecho un cambio, quiere que todos vean, en lugar de decir: "Tire de mi versión de Devapp", pueden decir: "He publicado mis cambios en nuestro repositorio principal". Es simplemente una convención fácil para que las personas se recuperen.
• Un clon es una copia de algún otro repositorio.Podría clonar el repositorio principal, hacer cambios y luego tú puedes clonar mi repositorio.Si realiza cambios, puede enviarlos al repositorio principal o al mío, siempre que la combinación sea válida y tenga permisos en la computadora.
• Un repositorio simple simplemente no tiene una "copia de trabajo": no hay un directorio "webroot" en esa computadora.esta vacio con solo el .git directorio, lo cual está bien para servidores donde nadie necesita modificar los archivos.

Finalmente, el .git dir no contiene los archivos de su repositorio, sino la configuración y la base de datos de git.Es el historial completo de su repositorio en forma de base de datos, que se utiliza para completar el resto del repositorio con una versión particular de su software.Por eso hice el comentario:puede en la zona verificar cualquier versión de cualquier realidad alternativa del repositorio, sin comunicación de red, en ningún momento, porque todo está ahí en el directorio .git.La única comunicación de red necesaria es cuando desea sincronizar su repositorio local a algún otro repositorio, usando push o pull.