workflows - Forma correcta de usar Git/GitHub-Sistema PHP con Dev/Testing/Servidores de producción

how github works

Question

Me disculpo si esto es obvio o fácil, he visto un buen número de tutoriales de git / github y he leído otros artículos, pero quiero asegurarme de que lo que hago es correcto.

Quiero incorporar VC (por razones obvias) en mi equipo y proceso de desarrollo.

Proceso de desarrollo actual (usando Dreamweaver):
* Recibir un boleto (u orden de trabajo)
* Descargar archivo en el servidor de Desarrollo
* Hacer cambios en el archivo
* Subir archivo de nuevo al servidor de desarrollo
* Cambios probados / verificados
* Enviar al servidor de producción

Estoy intentando descubrir cómo hacer nuestro nuevo proceso de desarrollo con el uso de Git.

Estoy cambiando a PHPStorm (que es un PHP IDE real con integración directa con Git).

¿Sería algo así como

• Recibir un boleto (u orden de trabajo)
• Pasar por caja / Actualizar / Descargar archivo (s)
• Cambiar archivos
• Subir archivo (que supongo que es también el directorio de trabajo actual ...?)
• Al final del día, haz un commit
• Haga que el script de compilación envíe datos al servidor de prueba (compilación nocturna)

¿O sería mejor hacer algo como

• Recibir un boleto (u orden de trabajo)
• Pasar por caja / Actualizar / Descargar archivo (s)
• Cambiar archivos
• Subir archivo / confirmar
• Haga que el script de compilación envíe datos al servidor de prueba (compilación nocturna)

¿O hay otra manera? ¿Tiene problemas para entender cuál sería el flujo óptimo?

Cualquier ayuda sería muy apreciada.

Editar

Estoy intentando ver si es mejor tener una versión del servidor localmente (cada desarrollador), y si es así, ¿cómo funciona eso si tienes 7 o más sucursales?

Si no, ¿cómo se manejan con 7 o más ramas con ellos en la web? ¿Transfiere archivos FTP o usa Git Hooks para que se actualicen automáticamente?

Actualización 26/07/2012

Después de trabajar exitosamente con Git por bastante tiempo, he seguido este modelo de ramificación con gran éxito: un exitoso modelo de ramificación de Git

La respuesta a lo anterior fue afirmativa: definitivamente debería tener una versión local del servidor.

Answer 1

Asumiendo que tienes un servidor en vivo y un servidor de desarrollo, yo haría algo en esta línea.

Antes incluso de comenzar con un ciclo de desarrollo, al menos tendría dos ramas:

1. Maestro: el servidor de desarrollo se ejecuta en esta rama
2. Estable: el servidor en vivo se ejecuta en esta rama.

Entonces, si un desarrollador obtiene un boleto o una orden de trabajo, él / ella realizará las siguientes acciones:

1. git pull origin master
2. git branch featureBranch (nombrado como id del ticket o como una buena descripción para la orden de trabajo)
3. git checkout featureBranch
4. Haga cambios que logren el cambio deseado. Comprometerse tantas veces como sea necesario. Haz esto porque crearás un historial valioso. Por ejemplo, puedes intentar un acercamiento a un problema y si no funciona, abandonarlo. Si un día después ves la luz y quieres volver a aplicar la solución, ¡está en tu historial!
5. Cuando la función está completamente desarrollada y probada localmente, consulte el maestro.
6. git merge featureBranch
7. git push origin master
8. Pruebe los cambios realizados en su servidor de desarrollo. Este es el momento de ejecutar cada prueba que se te ocurra.
9. Si todo está funcionando, combine la función o corrija en la rama estable. Ahora el cambio es en vivo para sus clientes.

Obtener el código en el servidor

La actualización de servidores no debería ser un problema. Básicamente los configuraría como usuarios como lo son tus desarrolladores. En mi empresa, configuramos los servidores como usuarios de solo lectura. Básicamente eso significa que los servidores nunca pueden empujar nada, pero siempre pueden tirar. Sin embargo, configurar esto no es trivial, así que podrías construir una interfaz web simple que simplemente permita un jit de extracción. Si puedes evitar que tus desarrolladores hagan cosas en implementaciones en vivo, estás a salvo :)

[EDITAR]

En respuesta a las últimas preguntas formuladas en los comentarios de esta reacción:

No sé si entiendo tu pregunta correctamente, pero básicamente (simplificado un poco) así es como haría esto, si estuviera en tu lugar.

La máquina de prueba (o la webroot que actúa como prueba de implementación) tiene su código fuente basado en un repositorio de git con la rama maestra prestada. Al crear este repositorio, incluso podría eliminar todas las demás referencias a todas las demás ramas, así que estará seguro de que no se puede obtener una rama incorrecta en este repositorio. Entonces, básicamente, la máquina de prueba tiene un repositorio de Git con solo una rama maestra que está desprotegida.

Para los servidores en vivo, haría exactamente lo mismo, pero esta vez con la rama estable desprotegida. El desarrollador debe tener un repositorio local clonado en el que existan todas las ramas. Y una implementación local del software que ustedes construyen. Este software obtiene su fuente de un repositorio git local. En otras palabras: de la rama actualmente desprotegida en este repositorio.

Codificación real

Cuando se desea una nueva característica, se puede crear una rama de función local en función del maestro actual. Cuando se desprotege la sucursal, el desarrollador puede realizar y verificar los cambios localmente (ya que el software se está ejecutando en el origen de la rama de características).

Si todo parece estar en orden, los cambios se fusionan de la rama de características a la maestra y se transfieren a su "máquina de git". "tu github" por así decirlo. Las pruebas ahora pueden extraer los cambios para que QA pueda realizar todas las pruebas necesarias. Si deciden que todo está bien, el desarrollador puede combinar los cambios de maestro a estable y volver a presionar.

Todo lo que queda ahora es tirar de tus máquinas en vivo.