Ich frage mich, ob jemand Erfahrung in der Arbeit an Django-Projekten in einem kleinen Team (3 in meinem Fall) hat, die Git Source Control Management verwenden.
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. Aber selbst dann scheint git die Dateien in dem Verzeichnis, das das Repository auf dem Server hält, nicht zu aktualisieren - wahrscheinlich, weil es die Änderungen nur speichert, um Speicherplatz 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 kann mir einfach keine Lösung ausdenken.
Wenn jemand ein ähnliches Problem überwunden hat, würde ich gerne hören, wie es geht.
Wenn Sie zu einem Remote-Repository wechseln, sind die besten Ergebnisse, wenn das Remote-Repository ein "blankes" Repository ohne Arbeitsverzeichnis ist. Es scheint, 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. Einen zentralen Ort zu haben, an dem jeder seine Arbeit vorantreiben muss, bevor er es überhaupt versuchen kann, wird zu viel Schmerz und Leid führen.
Für die Bereitstellung würde ich empfehlen, zu einem zentralen "nackten" Repository zu wechseln und dann einen Prozess auszuführen, bei dem der Implementierungsserver den neuesten Code aus dem zentralen Repository in sein Arbeitsverzeichnis zieht.
Wenn Sie zu einem (gemeinsamen) Git-Repository wechseln, werden die Arbeitsdateien dieses Repositorys nicht aktualisiert. Im Grunde, weil die Arbeitsdateien möglicherweise schmutzig 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 eines, das ich verwende, um das Unterverzeichnis "ui" auszuchecken und Apache verfügbar zu machen.
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 das 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 dies als Post-Update-Hook:
%Vor%Wie bereits erwähnt, überprüft dies das Unterverzeichnis "ui". Das ist das Bit ": ui", das new_tree_id setzt. Nehmen Sie einfach das ": ui" heraus (oder wechseln Sie zu "^ {tree}"), um alles auszuprobieren.
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 abgelegt und ein "aktueller" Symlink kann 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 aufwühlt, während Sie immer wieder Änderungen vornehmen ...
Hatte das gleiche Problem, auch mit Django arbeiten.
Stimmen Sie dem Testen vor Ort zu, wie bereits erwähnt.
Sie können dann die lokale Version auf einen neuen Zweig auf dem Server übertragen. 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 gedrängt haben, können Sie einen Git-Reset durchführen - hard. Alle Änderungen, die im aktuellen Arbeitszweig nicht festgelegt wurden, gehen jedoch verloren. Also pass auf dich auf.