Desarrollando proyectos de Django usando Git

Question

Me pregunto si alguien tiene experiencia trabajando en proyectos de Django en un equipo pequeño (3 en mi caso), usando la administración de control de fuente de Git.

El proyecto está alojado en un servidor de desarrollo, por lo que tengo un problema similar. Los desarrolladores no pueden ver si su código funciona hasta que confirmen sus cambios en su repositorio local, y luego envían esos cambios al servidor. Incluso entonces, sin embargo, git no parece estar actualizando los archivos dentro del directorio que contiene el repositorio en el servidor, probablemente porque solo almacena los cambios para ahorrar espacio.

Estamos empezando a pisarnos los pies cuando trabajamos en este proyecto, por lo que se necesita algún tipo de control de versión, pero no puedo encontrar una solución.

Si alguien ha superado un problema similar, me encantaría saber cómo se puede hacer.

Answer 1

Al pasar a un repositorio remoto, los mejores resultados se obtienen cuando el repositorio remoto es un repositorio "vacío" sin directorio de trabajo. Parece que tienes un directorio de trabajo en el repositorio remoto, que Git no actualizará cuando haga un push.

Para su situación, recomendaría que los desarrolladores tengan su propio entorno de prueba que puedan probar localmente antes de tener que enviar su código a otro lugar. Tener una ubicación central donde todo el mundo necesita impulsar su trabajo incluso antes de que intente le causará mucho dolor y sufrimiento.

Para el despliegue, recomendaría empujando a un repositorio central "desnudo", y luego tener un proceso en el que el servidor de implementación tira el último código del repositorio central en su directorio de trabajo.

Answer 2

Cuando ingresa a un repositorio de git (compartido), no actualiza los archivos de trabajo de ese repositorio. Básicamente porque los archivos de trabajo podrían estar sucios y en ese caso tendrías que fusionarte, y para eso necesitas tener acceso total al shell allí, lo que puede no ser el caso en general.

Si desea que se revise el "maestro" más reciente del repositorio compartido, puede organizarlo escribiendo un enlace de actualización posterior. Daré un ejemplo de uno a continuación que utilizo para verificar el subdirectorio "ui" y ponerlo a disposición de Apache.

Sin embargo, diré que creo que su proceso podría mejorarse. Por lo general, los desarrolladores necesitan servidores personales en los que puedan probar antes de pasar a un punto compartido: de lo contrario, el repositorio compartido probablemente sea terriblemente poco confiable. Considere, si presiono un cambio y no funciona, ¿es ese mi cambio lo que lo rompió o un efecto secundario de alguien más?

OK, yo uso esto como un gancho posterior a la actualización

#!/bin/sh 
# Should be run from a Git repository, with a set of refs to update from on the command line. 
# This is the post-update hook convention. 

info() { 
    echo "post-update: $@" 
} 

die() { 
    echo "post-update: $@" >&2 
    exit 1 
} 

output_dir=.. 
for refname in "$@"; do 
    case $refname in 
     refs/heads/master) 
      new_tree_id=$(git rev-parse $refname:ui) 
      new_dir="$output_dir/tree-$new_tree_id" 
      if [ ! -d "$new_dir" ]; then 
       info "Checking out UI" 
       mkdir "$new_dir" 
       git archive --format=tar $new_tree_id | (cd $new_dir && tar xf -) 
      fi 
      prev_link_target=$(readlink $output_dir/current) 
      if [ -n "$prev_link_target" -a "$prev_link_target" = "tree-$new_tree_id" ]; then 
       info "UI unchanged" 
      else 
       rm -f $output_dir/current 
       ln -snf "tree-$new_tree_id" "$output_dir/current" 
       info "UI updated" 
       title=$(git show --quiet --pretty="format:%s" "$refname" | \ 
        sed -e 's/[^A-Za-z][^A-Za-z]*/_/g') 
       date=$(git show --quiet --pretty="format:%ci" "$refname" | \ 
        sed -e 's/\([0-9]*\)-\([0-9]*\)-\([0-9]*\) \([0-9]*\):\([0-9]*\):\([0-9]*\) +0000/\1\2\3T\4\5\6Z/') 
       ln -s "tree-$new_tree_id" "$output_dir/${date}__${title}" 
      fi 
      ;; 
    esac 
done 

Como se ha mencionado, esto sólo comprueba hacia fuera el subdirectorio "ui". Ese es el bit ": ui" que establece new_tree_id. Solo saca el ": ui" (o cambia a "^ {tree}") para ver todo.

Las salidas van en el directorio que contiene el git repo, controlado por output_dir. El script espera ejecutarse dentro del git repo (que a su vez se espera que esté vacío): esto no es muy limpio.

Las salidas se colocan en directorios "tree-XXXX" y un enlace simbólico "actual" se las arregla para apuntar a la más reciente. Esto hace que el cambio de uno a otro sea atómico, aunque es poco probable que tome tanto tiempo que es importante.También significa revertir la reutilización de los archivos antiguos. Y también significa que consume espacio en disco a medida que avanzas en las revisiones ...

Answer 3

Tuve el mismo problema, también trabajé con django.

Acepte realizar pruebas localmente antes del despliegue, como ya se ha mencionado.

Puede empujar la versión local a una nueva bifurcación en el servidor. Luego haces una fusión con esta rama y el maestro. Después de esto, verá los archivos actualizados.

Si presionó accidentalmente la rama principal, puede hacer un reinicio de git --hard. Sin embargo, todos los cambios no comprometidos en la rama de trabajo actual se perderán. Así que ten cuidado.