Das deutsche Python-Forum

Hallo zusammen,

hier mal eine Frage an die GIT-Profis unter euch (ich gehöre da definitiv nicht dazu...)

Ich habe hier drei VMs:

• Einen Git-Server (gitlab)
• Einen Web-Server (apache)
• Einen einfachen Client

Ich kann

• auf dem Git-Server ein Projekt anlegen
• das dazu gehörige Repository auf dem Client klonen
• dort Änderungen durchführen
• diese comiten
• Auch der "push" läuft problemlos

Auf dem Web-Server kann ich das Repo ebenfalls problemlos klonen.
"pull" geht ebenfalls. (Genau das möchte ich automatisieren)

Dann dachte ich mir "Was, wenn jemand auf dem Web-Server was ändert?" Klar das dann ein "git pull" fehlschlägt.
Die Lösung, die ich über Google gefunden habe sieht so aus: Problem dabei: Der "git fetch" zieht sich nicht alles. Der neuste Commit fehlt ...
("git pull" wiederum funktioniert ...)

Derzeit nutze ich folgendes: Trotz funktionierender Lösung möchte ich doch gerne wissen, warum der "git fetch" nicht das tut, was ich erwarten würde ...

Das ist etwas verwirrend, du sagst:

midan23 hat geschrieben: ↑Mittwoch 17. Oktober 2018, 13:00
Auf dem Web-Server kann ich das Repo ebenfalls problemlos klonen.
"pull" geht ebenfalls. (Genau das möchte ich automatisieren)

Dann dachte ich mir "Was, wenn jemand auf dem Web-Server was ändert?" Klar das dann ein "git pull" fehlschlägt.
Die Lösung, die ich über Google gefunden habe sieht so aus:

Prinzipiell ist es bei Pull egal von *wo* aus du "ziehst", ein Unterschied besteht darin wie der Remote-Branch und deine lokalen Dateien aussehen. Bei einem git pull passiert im Grunde erstmal folgendes:

git fetch der die Änderungen vom Remote Repo zieht
git merge: was die remote und lokalen Dateien zusammenführt.

Bei einem reinen git fetch passiert das wiederrum nicht automatisch.

Mir ist dein UseCase noch nicht ganz klar. Was willst du genau erreichen?

Vorerst möchte auf dem Web-Server den gleiche Stand wie auf dem Git-Server haben können.
Wobei Änderungen auf dem Web-Server ignoriert werden sollen.

Du willst also einen Spiegelserver betreiben, wenn ich das richtig verstanden habe. Wie man da am besten vorgeht, wird hier erklärt:
https://help.github.com/articles/duplic ... r-location

@midan23: Änderungen auf dem Server können nur ignoriert werden wenn keine Konflikte beim mergen gibt — oder was sollte dann passieren?

Was ist denn der Grund warum das Arbeitsverzeichnis auf dem Server den gleichen Stand wie das Repository haben soll?

midan23 hat geschrieben: ↑Mittwoch 17. Oktober 2018, 13:41 Vorerst möchte auf dem Web-Server den gleiche Stand wie auf dem Git-Server haben können.
Wobei Änderungen auf dem Web-Server ignoriert werden sollen.

D.h. du möchtest deine lokalen Änderungen trotzdem behalten? Dann kannst du stash verwenden, um diese Änderungen "zu verstecken".
Somit kannst du einen aktuellen remote Branch ziehen ohne dass Git meckert weil du am lokalen Branch ebenfalls Änderungen hast.

Die Sache ist so geplant, das es auf dem Web-Server keine lokalen Änderungen geben soll.
In einer perfekten Welt könnte ich also davon ausgehen und bei einem einfachen "git pull" bleiben.
Da die Welt aber nicht perfekt ist (DAUs gibt es überall ...), muss ich mit unerwünschten lokalen Änderungen rechnen.
Und diese sollen komplett ignoriert werden.

Stellt euch einfach eine Reihe von Web-Entwicklern vor, die ihren Code einerseits über einen Git-Server teilen wollen und andererseits auf einem Web-Server die aktuellste Fassung ihrer Kreation sehen wollen.
(Denen keinen Zugriff auf den Web-Server zu geben wäre ja auch zu einfach ...)

@midan23: neben der Tatsache dass das ganze Szenario etwas abenteuerlich klingt würde ich auch sagen, dass das per se ja kein "Git-Problem" ist, sondern wer welche Berechtigung hat überhaupt Dateien zu manipulieren. IMO sollte man hier ansetzen und schauen, dass die Benutzer zwar die entsprechenden Files lesen aber nicht bearbeiten (also schreiben) dürfen.

midan23 hat geschrieben: ↑Mittwoch 17. Oktober 2018, 13:00

Code: Alles auswählen

git fetch
git clean -df
git reset --hard

Git ist kompliziert, und gerade mit den default-argumenten und Annahmen finde ich das immer sehr verwirrend. Meine Annahme, warum das *nicht* geht:

- git fetch updated deine remotes. NICHT deinen ausgecheckten working-tree!
- git reset --hard fehlt als weiteres Argument wie in der Hilfe beschrieben etwas commit-artiges. Nun ist die Frage was dann der implizite Wert ist. Und meine Vermutung ist: nicht was du denkst.

Wenn du hingegen

git reset --hard origin/branch

machst, *dann* sollte der auch den letzten commit uebernehmen.

Zur allgemeinen Frage, was da wie passiert etc - das klangt alles eher maessig gut. Meine Loesung fuer so etwas waere der Rueckgriff auf ein vernuenftiges Deployment Protokoll. Also zB mit ansible eine definierte Umgebung herstellen, und dabei dann eben einen konkreten branch/tag/commit frisch zugrunde legen. Damit erschlaegst du dann auch gleich noch andere Probleme wie sich aendernde Abhaengikeiten die installiert oder geupgradet werden muessten. Sowas sollte alles automitisiert sein.

@__deets__: Danke! Dein Tipp war goldrichtig.

Jetzt habe ich zwei funktionierende Möglichkeiten, um mein Ziel zu erreichen: und Andere Lösungen (Ansible oÄ.) wären zwar nett, aber viel zu aufwendig ...

Trotzdem: Danke an euch alle!