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 Ihrem eigenen Server ausführt.

Note

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

Um einen Git-Server einzurichten, müssen Sie ein bestehendes Repository in ein neues Bare-Repository exportieren – ein Repository, das kein Arbeitsverzeichnis enthält. Das ist im Allgemeinen einfach zu realisieren. Um Ihr Repository zu klonen, um ein neues nacktes Repository zu erstellen, führen Sie 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.

Sie sollten nun eine Kopie der Git-Verzeichnisdaten in Ihrem my_project.git Verzeichnis haben.

Das ist ungefähr so etwas wie

$ cp -Rf my_project/.git my_project.git

Es gibt ein paar kleine Unterschiede in der Konfigurationsdatei, aber für Ihren 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 Sie eine leere Kopie Ihres Repositories haben, müssen Sie es nur noch auf einen Server legen und Ihre Protokolle einrichten. Nehmen wir an, Sie haben einen Server mit der Bezeichnung git.example.com eingerichtet, auf den Sie SSH-Zugriff haben und Sie möchten alle Ihre Git-Repositorys unter dem Verzeichnis /srv/git speichern. Angenommen, /srv/git existiert bereits auf diesem Server, dann können Sie Ihr neues Repository einrichten, indem Sie Ihr leeres Repository kopieren:

$ 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, Ihr 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 Sie den Befehl git init mit der Option --shared ausführen. Beachten Sie, dass Sie durch die Ausführung dieses Befehls keine Commits, Referenzen usw. im laufenden Prozess zerstören werden.

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

Sie sehen, wie einfach es ist, ein Git-Repository zu übernehmen, eine leere Version zu erstellen und sie auf einem Server zu platzieren, auf den Sie und Ihre Mitarbeiter SSH-Zugriff haben. Jetzt sind Sie in der Lage, am gleichen Projekt mitzuarbeiten.

Es ist wichtig zu wissen, dass dies buchstäblich alles ist, was Sie tun müssen, um einen brauchbaren Git-Server zu betreiben, auf den mehrere Personen Zugriff haben – fügen Sie einfach SSH-fähige Konten auf einem Server hinzu und legen Sie ein leeres Repository an einen Ort, auf das alle diese Benutzer Lese- und Schreibrechte haben. Sie sind startklar – mehr ist nicht nötig.

In den nächsten Abschnitten erfahren Sie, wie Sie das zu komplexeren Konfigurationen erweitern können. Diese Betrachtung beinhaltet, dass man nicht für jeden Benutzer ein Benutzerkonto anlegen muss, öffentlichen Lesezugriff auf Repositories hinzufügen und Web-UIs einrichten kann und vieles mehr. Denken Sie 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 Sie ein kleines Team sind, Git nur in Ihrer Umgebung ausprobieren wollen und nur wenige Entwickler haben, kann es ganz einfach sein. Einer der kompliziertesten Aspekte bei der Einrichtung eines Git-Servers ist die Benutzerverwaltung. Wenn Sie möchten, dass einige Repositories 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 Sie einen Server haben, auf dem alle Ihre Entwickler bereits SSH-Zugriff haben, ist es in der Regel am einfachsten, dort Ihr erstes Repository einzurichten, da Sie so gut wie keine zusätzlichen Einstellungen vornehmen müssen (wie wir im letzten Abschnitt beschrieben haben). Wenn Sie komplexere Zugriffsberechtigungen für Ihre Repositories benötigen, können Sie diese mit den normalen Dateisystemberechtigungen des Betriebssystems Ihres Servers verwalten.

Wenn Sie Ihre Repositories auf einem Server platzieren möchten, der nicht über Konten für alle Personen in Ihrem Team verfügt, denen Sie Schreibzugriff gewähren möchten, müssen Sie für sie einen SSH-Zugriff einrichten. Wir gehen davon aus, dass auf Ihrem Server bereits ein SSH-Server installiert ist und Sie auf diesen Server zugreifen können.

Es gibt einige Möglichkeiten, wie Sie jedem in Ihrem Team Zugang gewähren können. Die erste besteht darin, Konten für alle einzurichten, was unkompliziert ist, aber schwerfällig 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 Methode besteht darin, ein einzelnes Git-Benutzerkonto auf der Maschine zu erstellen, jeden Benutzer, der Schreibrechte haben soll, aufzufordern, Ihnen einen öffentlichen SSH-Schlüssel zu senden, und diesen Schlüssel zur Datei ~/.ssh/authorized_keys dieses neuen Git-Kontos hinzuzufügen. Zu dem Zeitpunkt kann jeder über das Git-Konto auf diese Maschine zugreifen. Das hat keinen Einfluss auf die Commit-Daten – den SSH-Benutzer, den Sie anmelden, und auch nicht auf die Commits, die Sie gespeichert haben.

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