Entwickeln von Django-Projekten mit Git

Question

Ich frage mich, ob jemand Erfahrung in der Arbeit an Django-Projekten in einem kleinen Team (3 in meinem Fall), mit Git-Source-Control-Management hat.

Das Projekt wird auf einem Entwicklungsserver gehostet, weshalb ich ein solches Problem habe. Entwickler können nicht sehen, ob ihr Code funktioniert, bis sie ihre Änderungen in ihrem lokalen Repository festgeschrieben haben, und dann diese Änderungen auf den Server übertragen. Selbst dann scheint git die Dateien in dem Verzeichnis, das das Repository auf dem Server enthält, nicht zu aktualisieren - wahrscheinlich, weil es die Änderungen nur speichert, um Platz zu sparen.

Wir fangen an, uns bei der Arbeit an diesem Projekt auf die Füße zu treten, also ist eine Art Versionskontrolle erforderlich - aber ich finde einfach keine Lösung.

Wenn jemand ein ähnliches Problem überwunden hat, würde ich gerne hören, wie es geht.

Answer 1

Bei der Übertragung an ein Remote-Repository sind die besten Ergebnisse, wenn das Remote-Repository ein "blankes" Repository ohne Arbeitsverzeichnis ist. Es klingt, als hätten Sie ein Arbeitsverzeichnis im Remote-Repository, das bei einem Push nicht von Git aktualisiert wird.

Für Ihre Situation würde ich empfehlen, dass Entwickler ihre eigene Testumgebung haben, gegen die sie lokal testen können, bevor sie ihren Code irgendwo anders hinschieben müssen. Mit einem zentralen Ort, wo jeder seine Arbeit schieben muss, bevor sie versuchen können wird es zu viel Schmerz und Leid führen.

Für die Bereitstellung würde ich empfehlen, zu einem zentralen "nackten" Repository zu schieben, dann einen Prozess, wo der Deployment Server den neuesten Code aus dem zentralen Repository in sein Arbeitsverzeichnis zieht.

Answer 2

Wenn Sie zu einem (gemeinsamen) Git-Repository wechseln, werden die Arbeitsdateien dieses Repositorys nicht aktualisiert. Im Grunde, weil die Arbeitsdateien möglicherweise verschmutzt sind, und in diesem Fall müssten Sie zusammenführen --- und dafür müssen Sie vollen Shell-Zugriff haben, was im Allgemeinen nicht der Fall sein kann.

Wenn Sie möchten, dass der neueste "Master" des geteilten Repos irgendwo ausgecheckt wird, können Sie dafür sorgen, dass Sie einen Post-Update-Hook schreiben. Ich gebe ein Beispiel für ein Beispiel, das ich verwende, um das Unterverzeichnis "ui" auszuchecken und Apache zur Verfügung zu stellen.

Allerdings werde ich sagen, dass ich denke, dass Ihr Prozess verbessert werden könnte. Entwickler benötigen im Allgemeinen persönliche Server, auf denen sie testen können, bevor sie zu einem gemeinsamen Punkt drängen: andernfalls ist dieses gemeinsame Repo wahrscheinlich schrecklich unzuverlässig. Bedenke, wenn ich eine Veränderung anwende und es nicht funktioniert, ist das meine Veränderung, die es kaputt gemacht hat oder eine Nebenwirkung von jemand anderem?

OK, ich benutze diese als Post-Update Haken:

#!/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 

Wie bereits erwähnt, diese prüft nur die "ui" Unterverzeichnis aus. Das ist das Bit ": ui", das new_tree_id setzt. Nehmen Sie einfach das ": ui" heraus (oder wechseln Sie zu "^ {tree}"), um alles zu überprüfen.

Checkouts gehen in das Verzeichnis mit dem Git Repo, gesteuert von output_dir. Das Skript erwartet, dass es innerhalb des Git-Repos läuft (was wiederum erwartet wird, dass es leer ist): das ist nicht sehr sauber.

Checkouts werden in "tree-XXXX" -Verzeichnisse gestellt und ein "aktueller" Symlink konnte auf den neuesten verweisen. Das macht den Wechsel von Atom zu Atom, obwohl es wahrscheinlich nicht so lange dauern wird, dass es darauf ankommt.Es bedeutet auch, dass die alten Dateien wieder verwendet werden. Und es bedeutet auch, dass es Festplattenspeicher kaut, während Sie Revisionen vorantreiben ...

Answer 3

Hatte das gleiche Problem, auch mit Django arbeiten.

Stimmen Sie zu, wie bereits erwähnt, vor der Bereitstellung lokal zu testen.

Sie können dann die lokale Version auf einen neuen Zweig auf dem Server schieben. Dann führen Sie eine Zusammenführung mit dieser Verzweigung und dem Master durch. Danach sehen Sie die aktualisierten Dateien.

Wenn Sie versehentlich in den Master-Zweig geschoben, dann können Sie eine Git-Reset --hard tun. Alle Änderungen, die im aktuellen Arbeitszweig nicht festgelegt wurden, gehen jedoch verloren. Also pass auf dich auf.