Git
Chapters ▾ 2nd Edition

4.2 Git auf dem Server - Git auf einem Server einrichten

Git auf einem Server einrichten

Nun geht es darum, einen Git-Dienst einzurichten, der diese Protokolle auf deinem eigenen Server ausführt.

Anmerkung

Hier zeigen wir dir die Befehle und Schritte, die für die grundlegende, vereinfachte Installation auf einem Linux-basierten Server erforderlich sind. Es ist jedoch auch möglich, diese Dienste auf macOS- oder Windows-Servern auszuführen. Die tatsächliche Einrichtung eines Produktionsservers innerhalb deiner Infrastruktur wird sicherlich Unterschiede in Bezug auf Sicherheitsmaßnahmen oder Betriebssystemwerkzeuge mit sich bringen. Hoffentlich gibt dir dies einen Überblick darüber, worum es geht.

Um einen Git-Server einzurichten, musst du ein bestehendes Repository in ein neues Bare-Repository exportieren – ein Repository, das kein Arbeitsverzeichnis enthält. Das ist im Allgemeinen recht einfach zu realisieren. Um dein Repository zu klonen, um ein neues leeres Repository zu erstellen, führst du den Befehl clone mit der Option --bare aus. Normalerweise enden Bare-Repository-Verzeichnisnamen mit dem Suffix .git, wie hier:

$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.

Du solltest nun eine Kopie der Git-Verzeichnisdaten in deinem my_project.git Verzeichnis haben.

Das ist in etwa das selbe wie:

$ cp -Rf my_project/.git my_project.git

Es gibt ein paar kleine Unterschiede in der Konfigurationsdatei, aber für deinen Zweck ist das fast dasselbe. Es übernimmt das Git-Repository allein, ohne Arbeitsverzeichnis, und erstellt daraus ein eigenes Verzeichnis.

Das Bare-Repository auf einem Server ablegen

Jetzt, da du eine leere Kopie deines Repositorys hast, musst du es nur noch auf einen Server legen und die gewünschten Protokolle einrichten. Nehmen wir an, du hast einen Server mit der Bezeichnung git.example.com eingerichtet, auf dem du SSH-Zugriff hast und du möchtest alle deine Git-Repositorys unter dem Verzeichnis /srv/git ablegen. Angenommen, /srv/git existiert bereits auf diesem Server, dann kannst du dein neues Repository einrichten, indem du dein leeres Repository kopierst:

$ scp -r my_project.git user@git.example.com:/srv/git

Ab diesem Zeitpunkt können andere Benutzer, die SSH-basierten Lesezugriff auf das Verzeichnis /srv/git auf diesem Server haben, dein Repository klonen, indem sie Folgendes ausführen:

$ git clone user@git.example.com:/srv/git/my_project.git

Wenn sich ein Benutzer über SSH in einen Server einloggt und Schreibrechte auf das Verzeichnis /srv/git/my_project.git hat, hat er auch automatisch Push-Rechte.

Git fügt automatisch Schreibrechte für Gruppen zu einem Repository hinzu, wenn du den Befehl git init mit der Option --shared ausführst. Beachte, dass durch die Ausführung dieses Befehls keine Commits, Referenzen usw. im laufenden Prozess zerstört werden.

$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared

Du siehst, wie einfach es ist, aus einem Git-Repository eine leere Version zu erstellen und diese auf einem Server zu platzieren, auf den du und deine Mitstreiter SSH-Zugriff haben. Jetzt seid ihr der Lage, am gleichen Projekt zusammenzuarbeiten.

Das ist auch schon alles ist, was zu tun ist, um einen brauchbaren Git-Server zu betreiben, auf den mehrere Personen Zugriff haben. Füge einfach SSH-fähige Konten auf einem Server hinzu und lege ein leeres Repository an einen Ort, auf das alle diese Benutzer Lese- und Schreibrechte haben. Ihr seid nun startklar – mehr ist nicht nötig.

In den nächsten Abschnitten erfährst du, wie du dieses Grundkonstrukt zu komplexeren Konfigurationen erweitern kannst. Das beinhaltet, dass man nicht für jeden Benutzer ein Benutzerkonto anlegen muss, öffentlichen Lesezugriff auf Repositorys hinzufügt und Web-UIs einrichtet und vieles mehr. Denke jedoch daran, dass zur Zusammenarbeit mit ein paar Personen bei einem privaten Projekt nur ein SSH-Server und ein Bare-Repository benötigt wird.

Kleine Installationen

Wenn Ihr ein kleines Team seid, die Git nur in einer kleinen Umgebung ausprobieren wollen und nur wenige Entwickler habt, kann es ganz einfach sein. Einer der kompliziertesten Aspekte bei der Einrichtung eines Git-Servers ist die Benutzerverwaltung. Wenn du möchtest, dass einige Repositorys für bestimmte Benutzer schreibgeschützt und für andere lesend und schreibend sind, können Zugriff und Berechtigungen etwas schwieriger zu realisieren sein.

SSH-Zugang

Wenn du einen Server hast, auf dem alle deine Entwickler bereits SSH-Zugriff haben, ist es in der Regel am einfachsten, dort ein erstes Repository einzurichten. Du musst so gut wie keine zusätzlichen Einstellungen vornehmen, wie wir im letzten Abschnitt beschrieben haben. Wenn du komplexere Zugriffsberechtigungen für deine Repositorys benötigst, kannst du diese mit den normalen Dateisystemberechtigungen des Betriebssystems deines Servers verwalten.

Wenn du deine Repositorys auf einem Server platzieren möchtest, der nicht über Konten für alle Personen in deinem Team verfügt, denen du Schreibzugriff gewähren möchtest, musst du für sie einen SSH-Zugriff einrichten. Wir gehen davon aus, dass auf deinem Server bereits ein SSH-Server installiert ist und du auf diesen Server zugreifen kannst.

Es gibt einige Möglichkeiten, wie du jedem in deinem Team Zugang gewähren kannst. Die erste besteht darin, Konten für alle einzurichten, was unkompliziert ist, aber recht mühsam sein kann. Unter Umständen ist es ratsam, adduser (oder die mögliche Alternative useradd) nicht auszuführen und für jeden neuen Benutzer temporäre Passwörter festzulegen.

Eine zweite Möglichkeit besteht darin, ein einzelnes Git-Benutzerkonto auf der Maschine zu erstellen. Fordere anschließend jeden Benutzer, der Schreibrechte haben möchte auf, dir seinen öffentlichen SSH-Schlüssel zu senden. Diesen Schlüssel fügst du nun zur Datei ~/.ssh/authorized_keys des neuen 'git' Kontos hinzu. Jetzt sollte jeder über das 'git' Konto auf die Maschine zugreifen können. Das hat keinen Einfluss auf die committeten Daten. Der SSH-Benutzer mit dem du dich anmeldest hat keinen Einfluss auf deine aufgezeichneten Commits.

Eine weitere Möglichkeit besteht darin, dass sich dein SSH-Server von einem LDAP-Server oder einer anderen zentralen Authentifizierungsquelle authentifiziert, den du möglicherweise bereits eingerichtet hast. Solange jeder Benutzer Shell-Zugriff auf die Maschine erhalten kann, sollte jeder denkbare SSH-Authentifizierungsmechanismus funktionieren.

scroll-to-top