Uso de 'git pull' frente a 'git checkout -f' para la implementación del sitio web

Question

He encontrado dos enfoques comunes para implementar automáticamente las actualizaciones del sitio web mediante un repositorio remoto simple.

La primera requiere que el repositorio se clone en la raíz del documento del servidor web y en el gancho posterior a la actualización se utiliza un git pull.

cd /srv/www/siteA/ || exit 
unset GIT_DIR 
git pull hub master 

El segundo enfoque agrega un 'árbol de trabajo independiente' al depósito desnudo. El post-recibir gancho utiliza git checkout -f para replicar la cabeza del repositorio en el directorio de trabajo que es el ejemplo servidores web documento raíz

GIT_WORK_TREE=/srv/www/siteA/ git checkout -f 

El primer enfoque tiene la ventaja de que los cambios realizados en los sitios web de directorio de trabajo puede ser comprometido y devuelto al repositorio simple (sin embargo, los archivos no deben actualizarse en el servidor activo). El segundo enfoque tiene la ventaja de que el directorio git no se encuentra dentro de la raíz del documento, pero esto se resuelve fácilmente usando htaccess.

¿Hay un método objetivamente mejor que el otro en términos de mejores prácticas? ¿Qué otras ventajas y desventajas me estoy perdiendo?

Answer 1

En términos de administración de versiones (aquí implementación), es mejor tener un entorno de destino que sea independiente del mecanismo de liberación.
En otras palabras, la segunda solución (checkout -f) modificará una estructura de directorio web simple, sin ningún otro subdirectorio que no deba ser parte de él (como una carpeta .git).
Lo uso, por ejemplo, en "using git to deploy my node.js app to my production server".

Eso minimiza cualquier efecto secundario y permite que el entorno de producción funcione con exactamente lo que necesita para funcionar, sin interferencias.