Flujo de trabajo de Git en el desarrollo de sitios web con gancho automatizado: Git pull o git clone?

Antes que nada, gracias por tu time leyendo esta pregunta.

Actualmente estoy investigando sobre qué flujo de trabajo de Git es más adecuado para el desarrollo de sitios web en la empresa para la que trabajo. Hay diferentes guías en toda la networking, pero en su mayoría son conceptuales. Por favor, avíseme si mi forma de implementarlo es incorrecta:

1. El concepto

Conceptualmente habría 4 niveles, desarrollo, integración, puesta en escena y producción. el nivel de desarrollo se almacena localmente, la integración se hace con la ayuda de Git, el nivel de producción se encuentra directamente en public_html y el nivel intermedio para get una vista previa del sitio antes de que la versión esté disponible en un directory protegido __dev / staging (o mejor aún, __dev / [branch_name]? )

2. Estructura de la carpeta (etapas y niveles de producción)

  • git
    • project.git (este es el repository simple de este proyecto de website)
  • public_html
    • __dev (directory protegido con contraseña)
      • puesta en escena (esto es como una copy de public_html utilizada como nivel de transición)

3. Configuración de Git dentro de mi copy local (niveles de desarrollo e integración)

git remote add origin ssh://path_to_project.git git branch staging 

De esa forma tengo dos twigs para comenzar, maestra y puesta en escena.

Cuando lo hago

 git push origin master 

La versión en línea del sitio debe actualizarse sin que tenga que conectarme al sitio. Y cuando lo hago

 git push origin [branchname] 

__dev / [branchname] se debe actualizar automáticamente.

Todo lo anterior podría hacerse a través de ganchos git. La razón de esta automation en lugar de ssh connect y pull es que permite un desarrollo más rápido (de lo contrario, si se necesita más esfuerzo que ftp, ¿para qué? / ¿Estás de acuerdo?)

4. Gancho

Aquí es donde me confundí bastante.

Lo que tenía en mente era cualquiera de estos dos sabores:

a. clonar y copyr

Cuando presiono en el sitio, el gancho clonará el repository desnudo en un directory temporal y lo copyrá en public_html o __dev / branch dependiendo de qué twig envíe.

segundo. restablecer y tirar

Cuando presiono en el sitio, el gancho comprobará si ya hay un directory .git dentro de public_html o __dev / branch

Si no se encuentra ninguno, cd a ese directory y git init, entonces git pull.

Si se encuentra, cd a ese directory y git reset –head then git pull

Instalación de la aplicación usando installatron o softaculous

A veces me gusta instalar la aplicación web desde installatron y usarla como base de trabajo. Lamentablemente, no hay ningún gancho para enviar automáticamente a Git después de la installation, así que tengo que conectarme a ssh y hacer:

 git add . git commit -a -m "installed xxx app" git push origin master 

Luego tire de él en mi repository local.

Conclusión y pregunta

¿Qué piensas sobre el flujo de trabajo que tenía en mente? ¿Hay algún lugar que necesite mejorar? ¿Está bien la disposition de las twigs? Qué sabor es mejor 4.a. o 4.b., o hay otro?

Gracias.

Ambos 4a y 4b son comúnmente utilizados.

Prefiero 4b, ya que tiene todo el historial de su repo disponible en la carpeta de producción. Puedes ver más en:

  • restablecer duro en git push
  • Escribir un gancho git post-receive para tratar con una twig específica
  • otros enfoques de implementación

En cuanto a las sucursales, comience de forma simple y agréguelas cuando sea necesario.
Pero no olvide que con un VCS distribuido , puede enviarlo a un repository intermedio, que puede notificar a un planificador de tareas como Jenkins de una nueva confirmación , para ejecutar algunas testings.
Si esas testings pasan, entonces puede presionar al repo de prod.