Repo de Git – en un server web

Tener un proyecto web en un server web compartido por algunos desarrolladores me lleva a configurar el repository de Git para ese proyecto.
Pero todavía tengo algunas dudas sobre cómo organizarlo.

Supongamos que tengo mis proyectos web en /var/www/

Algunas preguntas, ideas Me gustaría recibir comentarios:

¿Es mejor init el repository git en la misma carpeta de publicación, o crear /var/repo/ , copyr contenidos dentro e init /var/repo/ en estas copys del proyecto?

En el primer caso, ¿puedo ramificar el proyecto como superuser y permitir que las personas trabajen en esta twig … y luego decidir fusionar las twigs una vez probadas? Pero en este caso, no creo que las personas puedan probar su trabajo fácilmente en el server web … deberían necesitar un entorno local. configurado para la testing.

Si creo el /var/repo/domain.com , sería bueno crear Vhosts como http://git.domain.com para que los desarrolladores prueben su trabajo comprometido.

Si tengo el /var/repo/project.com y me gusta publicar el trabajo comprometido (por ejemplo, copyr los files en /var/www/project.com ), ¿cómo debo realizar esta acción de copy? Con cp -R ? ¿Ya hay una herramienta para realizar esta actualización cuando sea necesario?

En primer lugar, no debería hacer que su proyecto web sea el repository en sí. Primero debe configurar un repository para que todos puedan acceder. Puede tener un maestro y una twig de desarrollo y todos también podrían tener sucursales propias para partes especiales de la aplicación web. La mejor solución es tener su repository en un server diferente de su sistema en vivo. Si no quieres probar cosas localmente, debes configurar un server de desarrollo / estadificación para que la gente pueda probar las cosas allí. El mejor procedimiento es usar un script de deployment para eso, por ejemplo, Capistrano.

Su procedimiento debe ser así: Servidor A: Repositorio con un maestro y una twig de etapas + otras twigs si es necesario para el desarrollo. Servidor B: Live System (puede usar capistrano para implementar la twig maestra aquí; si quiere ser el único que puede implementar en el sistema en vivo, no debe agregar ninguna key ssh al server sino la suya o usar otra). método de authentication) Servidor C: entorno de testing (también podría estar en el mismo server como sus repositorys, pero yo personalmente prefiero este separado también)

Ahora use capistrano para vincular el sistema en vivo con la twig principal y el sistema de testing con la twig dev / staging. La gente debería tener acceso ssh al server de etapas, por supuesto.

Pueden enviar sus cambios al repository usando la twig dev / staging. Después de eso, pueden usar 'implementación de puesta a testing de límites' para implementar la twig de desarrollo / etapas en el server de desarrollo para probar su trabajo. Si todo funciona, simplemente puede tirar de la twig de desarrollo y salir del maestro. Use 'git merge staging' para fusionar la twig dev / staging en el master y empújela al repository principal. Luego, un 'deployment de producción de tapa' instalaría todo en su sistema en vivo.

Es bastante fácil de configurar, solo unas pocas cosas de configuration para todos y tendrías un gran flujo de trabajo.

Espero que haya ayudado.