Kapitel ▾ 2. Auflage

4.2 Git auf dem Server - Git auf einem Server einrichten

Git auf einem Server einrichten

Nun werden wir die Einrichtung eines Git-Dienstes behandeln, der diese Protokolle auf Ihrem eigenen Server ausführt.

Hinweis

Hier demonstrieren wir die Befehle und Schritte, die für einfache, vereinfachte Installationen auf einem Linux-basierten Server erforderlich sind, obwohl es auch möglich ist, diese Dienste auf macOS- oder Windows-Servern auszuführen. Die tatsächliche Einrichtung eines Produktionsservers innerhalb Ihrer Infrastruktur wird sicherlich Unterschiede bei Sicherheitsmaßnahmen oder Betriebssystemwerkzeugen mit sich bringen, aber hoffentlich vermittelt Ihnen dies die allgemeine Vorstellung davon, was involviert ist.

Um einen Git-Server zunächst einzurichten, müssen Sie ein bestehendes Repository in ein neues Bare-Repository exportieren – ein Repository, das kein Arbeitsverzeichnis enthält. Dies ist im Allgemeinen unkompliziert. Um Ihr Repository zu klonen und ein neues Bare-Repository zu erstellen, führen Sie den Klon-Befehl mit der Option --bare aus. Konventionsgemäß enden die Namen von Bare-Repository-Verzeichnissen mit der Endung .git, wie folgt

$ 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 Verzeichnis my_project.git haben.

Dies ist ungefähr gleichbedeutend mit

$ cp -Rf my_project/.git my_project.git

Es gibt ein paar kleinere Unterschiede in der Konfigurationsdatei, aber für Ihren Zweck ist dies fast dasselbe. Es nimmt das Git-Repository allein, ohne Arbeitsverzeichnis, und erstellt ein Verzeichnis speziell dafür.

Das Bare-Repository auf einem Server platzieren

Nachdem Sie eine Bare-Kopie Ihres Repositorys haben, müssen Sie es nur noch auf einen Server legen und Ihre Protokolle einrichten. Nehmen wir an, Sie haben einen Server namens git.example.com eingerichtet, zu dem Sie SSH-Zugriff haben, und Sie möchten alle Ihre Git-Repositorys unter dem Verzeichnis /srv/git speichern. Unter der Annahme, dass /srv/git auf diesem Server existiert, können Sie Ihr neues Repository einrichten, indem Sie Ihr Bare-Repository kopieren

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

An diesem Punkt können andere Benutzer, die SSH-basierten Lesezugriff auf das Verzeichnis /srv/git auf diesem Server haben, Ihr Repository klonen, indem sie

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

Wenn sich ein Benutzer per SSH auf einem Server anmeldet und Schreibzugriff auf das Verzeichnis /srv/git/my_project.git hat, hat er automatisch auch Push-Zugriff.

Git fügt automatisch Gruppen-Schreibberechtigungen zu einem Repository hinzu, wenn Sie den Befehl git init mit der Option --shared ausführen. Beachten Sie, dass Sie durch Ausführen dieses Befehls keine Commits, Refs usw. zerstören.

$ 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 nehmen, eine Bare-Version zu erstellen und es auf einem Server zu platzieren, zu dem Sie und Ihre Mitarbeiter SSH-Zugriff haben. Nun sind Sie bereit, am selben Projekt zusammenzuarbeiten.

Es ist wichtig zu beachten, dass dies buchstäblich alles ist, was Sie tun müssen, um einen nützlichen Git-Server zu betreiben, zu dem mehrere Personen Zugriff haben – fügen Sie einfach SSH-fähige Konten auf einem Server hinzu und legen Sie ein Bare-Repository irgendwo ab, zu dem alle diese Benutzer Lese- und Schreibzugriff haben. Sie sind bereit – nichts weiter nötig.

In den nächsten Abschnitten erfahren Sie, wie Sie zu anspruchsvolleren Setups erweitern können. Diese Diskussion wird beinhalten, dass Sie keine Benutzerkonten für jeden Benutzer erstellen müssen, öffentlichen Lesezugriff auf Repositories hinzufügen, Web-UIs einrichten und mehr. Behalten Sie jedoch im Hinterkopf, dass Sie für die Zusammenarbeit mit ein paar Leuten an einem privaten Projekt nur einen SSH-Server und ein Bare-Repository benötigen.

Kleine Setups

Wenn Sie eine kleine Organisation sind oder Git gerade in Ihrem Unternehmen ausprobieren und nur wenige Entwickler haben, kann es für Sie 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 lesbar/schreibbar sind, kann der Zugriff und die Berechtigungen etwas schwieriger zu regeln sein.

SSH-Zugriff

Wenn Sie einen Server haben, zu dem alle Ihre Entwickler bereits SSH-Zugriff haben, ist es im Allgemeinen am einfachsten, Ihr erstes Repository dort einzurichten, da Sie fast keine Arbeit leisten müssen (wie im letzten Abschnitt behandelt). Wenn Sie komplexere Zugriffskontrollberechtigungen für Ihre Repositories wünschen, können Sie diese mit den normalen Dateisystemberechtigungen des Betriebssystems Ihres Servers handhaben.

Wenn Sie Ihre Repositories auf einem Server platzieren möchten, der keine Konten für alle Mitglieder Ihres Teams hat, denen Sie Schreibzugriff gewähren möchten, müssen Sie ihnen SSH-Zugriff einrichten. Wir gehen davon aus, dass Sie bereits einen SSH-Server installiert haben, wenn Sie über einen Server verfügen, mit dem Sie dies tun können, und dass Sie auf diese Weise auf den Server zugreifen.

Es gibt mehrere Möglichkeiten, jedem in Ihrem Team Zugriff zu gewähren. Die erste besteht darin, für jeden ein Konto einzurichten, was unkompliziert, aber umständlich sein kann. Möglicherweise möchten Sie nicht adduser (oder die mögliche Alternative useradd) ausführen und für jeden neuen Benutzer temporäre Passwörter festlegen.

Eine zweite Methode ist die Erstellung eines einzigen "git"-Benutzerkontos auf der Maschine. Bitten Sie jeden Benutzer, der Schreibzugriff haben soll, Ihnen einen öffentlichen SSH-Schlüssel zuzusenden, und fügen Sie diesen Schlüssel der Datei ~/.ssh/authorized_keys dieses neuen "git"-Kontos hinzu. Zu diesem Zeitpunkt kann jeder über das "git"-Konto auf diese Maschine zugreifen. Dies hat keine Auswirkungen auf die Commit-Daten – der SSH-Benutzer, mit dem Sie sich verbinden, hat keine Auswirkungen auf die aufgezeichneten Commits.

Eine andere Möglichkeit ist, dass Ihr SSH-Server von einem LDAP-Server oder einer anderen zentralen Authentifizierungsquelle authentifiziert, die Sie möglicherweise bereits eingerichtet haben. Solange jeder Benutzer eine Shell-Sitzung auf der Maschine erhalten kann, sollte jeder SSH-Authentifizierungsmechanismus, den Sie sich vorstellen können, funktionieren.