Versionskontrolle auf einem Server mit Git

Wieso eine Versionskontrolle auf einem Server?

Da kann es verschiedene Gründe für geben. Der Hauptgrund wieso wir eine Versionskontrolle für verschiedene Bereiche auf unseren Servern haben ist, das wir lokal programmieren wollen. Das bedeutet die Dateien auf dem Server werden nur durch Git geändert und nicht durch einen User selbst. Das hat den Vorteil das es eine saubere Versionshistorie gibt und man jede Änderung zurückverfolgen bzw. sogar schnell und einfach zurück drehen kann.

Was sind die Voraussetzungen für eine Versionskontrolle auf einem Server?

Auf dem Server sollte Git installiert sein, ihr solltet Git lokal installiert haben und ein Verwaltungsprogramm für eure Git-Repositories haben. Wir nutzen hierfür „Atlassian Stash“, welches sich gut mit anderen Tools kombinieren lässt (z.B. Atlassian Jira oder Hudson).

 

Wie funktioniert nun eine Versionskontrolle auf einem Server?

Für meine Erläuterungen gehe ich von dem Stand aus, das Git sowohl lokal als auch auf dem Server installiert ist und ein Verwaltungsprogramm für Git-Repositories vorhanden ist. Weiterhin das ein lokales Arbeitsverzeichnis vorhanden ist.

1.Bare-Repository

Zu aller erst muss auf dem entsprechenden Server ein Bare-Repository eingerichtet werden. Ein Bare-Repository dient dazu die lokal geänderten Daten auf den Server zu pushen und dann zu verteilen. Um dieses anzulegen wechseln ihr in ein Verzeichnis wo, falls notwendig, auch weitere Bare-Repositories angelegt werden können. Zum Beispiel könnten sie im Ordner „root“ einen Ordner für die Bare-Repositories anlegen. Darin legt ihr ein Verzeichnis mit einem beliebigen Name und dem Suffix .git an (diese Endung ist eine Konvention). Das Bare-Repository ist damit fast fertig. Nun einfach per Konsole in das Verzeichnis wechseln und folgenden Befehl ausführen:

 

Dieser erstellt das Bare-Repository in diesem Verzeichnis. Damit wäre die Grundlage um eine Versionskontrolle auf einem Server durchzuführen geschaffen.

2.Arbeitsbereich auf dem Server

Nun muss der Arbeitsbereich auf dem Server eingerichtet werden. Dazu wechselt ihr in das Verzeichnis welches ihr mit Git kontrollieren wollt. Hierbei gibt es zwei verschiedene Szenarien. Entweder das Verzeichnis ist leer oder es sind schon eure Daten darin.

2.a ein leeres Verzeichnis

Ihr wechselt in das Oberverzeichnis wo ihr euer Arbeitsverzeichnis anlegen wollt. Nun wird das Bare-Repository geklont und ihr laßt euch von diesem Befehl euren Arbeitsordner gleich erstellen:

 

2.b ein Verzeichnis mit Dateien

Um ein gefülltes Arbeitsverzeichnis mit einem Bare-Repository zu verbinden wechselt ihr in dieses Verzeichnis und initialisiert dort Git. Dazu nutzt ihr folgende Befehle:

 

Nun muss das Arbeitsverzeichnis nur noch mit dem Bare-Repository verbunden werden und der aktuelle Stand in das Bare-Repository gepusht werden. Hierfür werden folgende Befehle genutzt:

 

Damit wäre das Arbeitsverzeichnis und das Bare-Repository für das Arbeiten mit Versionskontrolle vorbereitet.

 

 

Wie funktioniert nun das Arbeiten mit dem Bare-Repository?

Von nun an kann lokal entwickelt werden. Wenn Änderungen gemacht wurden können diese ganz normal in das Verwaltungsprogramm gepusht werden. Um diese Änderungen nun auf den Server zu pushen empfiehlt es sich vorher erst einen Remote-Namen für das Bare-Repository anzulegen.

 

WICHTIG: Da dieser Befehl lokal ausgeführt wird muss der Pfad zum Bare-Repository die komplette Verbindungs-URL sein. D.h. „ssh://Benutzer@Server-IP.de/…“ .

Jetzt könnt ihr eure lokalen Änderungen ganz einfach in der Verwaltungsprogramm und danach auf den Server pushen, natürlich nachdem ein Commit gemacht wurde. Der Befehl für den push in das Verwaltungsprogramm ist folgender:

 

Um die Änderungen nun auf den Server zu pushen ist folgender Befehl notwendig:

 

Mit diesem Befehl schiebt ihr eure Änderungen in das Bare-Repository auf dem Server. Nun müsst ihr am besten mittels ssh-Befehl auf den Server wechseln. Dann springt ihr in das Git-Verzeichnis (Arbeitsverzeichnis) und zieht die Änderungen aus dem Bare-Repository.

 

Damit sind eure lokalen Anpassungen in dem Verwaltungsprogramm und auf dem Server.

Diese Grafik soll den Ablauf nochmal verdeutlichen.

 

kma_git_bare_repo

 

Zusammenfassung / Fazit

Mit dieser Methode macht ihr zwei Schritte zusätzlich, jedoch könnt ihr lokal entwickeln und nicht jeder entwickelt live auf dem Server. Des weiteren habt ihr damit eine Änderungshistory und könnt bei Bedarf auch auf ältere Stände zurück springen. Es kann auch mit Branches gearbeitet werden, was verschiedene Entwicklungsstände sauber voneinander trennt.

Also alles in allem habt ihr zwar ein bisschen mehr Aufwand, aber sehr viele positive Effekte welche spätere Fehler vermeiden bzw. leichter Rückgängig machen lässt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.