dedlfix: 2 lokale Webserver Änderungen transportieren ?

Beitrag lesen

Tach!

Ich habe bisher keine einzige Datei auf meinem lokalen Arbeitsplatz. Ich habe auf meinem PC 2 Laufwerksmappings. Laufwerk T: zeigt auf auf das /srv/www/htdocs vom Testserver (Entwicklungsserver), Laufwerk P: zeigt entsprechend auf das Produktivsystem. Mein Kollege ebenso.

Wo erstelle ich dann sinnvollerweise das Bare-Repo?

Ein Bare-Repo ist eins ohne Arbeitsverzeichnis. Man nimmt es nur, um eine Kopie des Repos zu verwalten, ohne Änderungen am Inhalt vorzunehmen. Das kommt also an eine zentrale Stelle, und wird auf den Repos mit Arbeitsverzeichnis als Remote eingetragen. Jeder Entwickler pusht seine Commits dorthin und aktualisiert darüber seine Kopie mit den Änderungen der anderen. Konsumenten holen sich dort den neuesten Stand (oder den vom Produktiv-Branch, aber Brachen ist wieder eine Geschichte für sich, die für den ersten Anfang nicht benötigt wird).

Wenn ich vorher ein Repo von Laufwerk T gemacht habe, kann ich doch erst dann Pushen, wenn das Bare-Repo als Remote angegeben wurde oder?

Jedes Repo ist an sich gleichwertig. Dass das eine kein Arbeitsverzeichnis hat, spielt für das Synchronisieren von Repos keine Rolle. Es spielt auch keine Rolle, in welcher Reihenfolge sie eingerichtet werden, nur müssen sie leer sein, wenn sie mit einem anderen verbunden werden sollen, das schon Daten hat. Aber ich erklär das mal an meiner üblichen Vorgehensweise. (Man kann auch anders vorgehen, viele Wege führen nach Rom). Zuerst erstell ich mir ein lokales Repo mit Arbeitsverzeichnis. Da kommen meine ersten Commits rein, wenn schon welche da sind. Dann leg ich ein zentrales Repo als Bare an. In meinem Fall ist das meist auf einer Gogs-Installation, kann aber genausogut mit Kommandozeile oder jedem anderen Verwaltungsprogramm erfolgen. Dieses zentrale Repo wird nun als Remote bei meinem anderen eingetragen und ich kann nun mit Push die Commits vom lokalen in das zentrale kopieren. Alle weiteren Repos werden direkt als Clone von diesem zentralen erzeugt und sind dann bereits fertig konfiguriert (zumindest mit meinen Tools, ob die CLI das gleich als Remote konfiguriert, weiß ich nicht).

Das werde ich direkt probieren, sobald mir klar ist, wo das zentrale Repo liegen soll.

Auf irgendeiner Server-Maschine. Das kann zur Not auch der produktive Server sein. Und wenn man noch mehr Not hat, legt man das mit Arbeitsverzeichnis im VHost des Webservers an. Besser wäre aber, ein Bare-Repo als zentrales zumindest irgendwo abseits des VHosts zu haben. Dazu ein weiteres mit Arbeitsverzeichnis im VHost.

Es ist auch sehr empfehlenswert, darauf zu achten, dass das .git-Verzeichnis nicht via Web-Request befragt werden kann. Da liegen teilweise sensible Daten drin, die man nicht veröffentlichen möchte.

dedlfix.