4.1 Git auf dem Server - Die Protokolle

Die Vorteile von dateibasierten Repositories sind, dass sie einfach sind und vorhandene Dateiberechtigungen und Netzwerkzugriff nutzen. Wenn Sie bereits ein gemeinsam genutztes Dateisystem haben, auf das Ihr gesamtes Team Zugriff hat, ist die Einrichtung eines Repositorys sehr einfach. Sie legen die Bare-Repository-Kopie irgendwo ab, auf das alle gemeinsamen Zugriff haben, und legen die Lese-/Schreibberechtigungen fest, wie Sie es für jedes andere gemeinsam genutzte Verzeichnis tun würden. Wir werden in Getting Git on a Server besprechen, wie eine Bare-Repository-Kopie für diesen Zweck exportiert wird.

Dies ist auch eine gute Option, um schnell Arbeiten aus dem Arbeitsverzeichnis eines anderen zu holen. Wenn Sie und ein Kollege am selben Projekt arbeiten und er möchte, dass Sie etwas überprüfen, ist die Ausführung eines Befehls wie git pull /home/john/project oft einfacher, als wenn er zu einem entfernten Server überträgt und Sie dann von dort abrufen.

Die Nachteile dieser Methode sind, dass der gemeinsame Zugriff im Allgemeinen schwieriger einzurichten und von mehreren Standorten aus zu erreichen ist als einfacher Netzwerkzugriff. Wenn Sie von Ihrem Laptop aus übertragen möchten, wenn Sie zu Hause sind, müssen Sie die entfernte Festplatte einhängen, was im Vergleich zum netzwerkbasierten Zugriff schwierig und langsam sein kann.

Es ist wichtig zu erwähnen, dass dies nicht unbedingt die schnellste Option ist, wenn Sie eine Art von gemeinsam genutztem Mount verwenden. Ein lokales Repository ist nur schnell, wenn Sie schnellen Zugriff auf die Daten haben. Ein Repository auf NFS ist oft langsamer als das Repository über SSH auf demselben Server, wodurch Git lokale Festplatten auf jedem System nutzen kann.

Schließlich schützt dieses Protokoll das Repository nicht vor versehentlicher Beschädigung. Jeder Benutzer hat vollen Shell-Zugriff auf das "entfernte" Verzeichnis, und nichts hindert ihn daran, interne Git-Dateien zu ändern oder zu entfernen und das Repository zu beschädigen.

Smart HTTP funktioniert sehr ähnlich wie die SSH- oder Git-Protokolle, läuft jedoch über Standard-HTTPS-Ports und kann verschiedene HTTP-Authentifizierungsmechanismen verwenden, was bedeutet, dass es für den Benutzer oft einfacher ist als etwas wie SSH, da Sie z. B. die Authentifizierung mit Benutzername/Passwort verwenden können, anstatt SSH-Schlüssel einrichten zu müssen.

Es ist wahrscheinlich die beliebteste Art geworden, Git jetzt zu verwenden, da es so eingerichtet werden kann, dass es anonym wie das git://-Protokoll bedient, und auch mit Authentifizierung und Verschlüsselung wie das SSH-Protokoll übertragen werden kann. Anstatt verschiedene URLs für diese Dinge einrichten zu müssen, können Sie jetzt eine einzige URL für beides verwenden. Wenn Sie versuchen zu übertragen, und das Repository eine Authentifizierung benötigt (was es normalerweise tun sollte), kann der Server nach einem Benutzernamen und Passwort fragen. Dasselbe gilt für den Lesezugriff.

Tatsächlich ist für Dienste wie GitHub die URL, die Sie zum Anzeigen des Repositorys online verwenden (z. B. https://github.com/schacon/simplegit), dieselbe URL, die Sie zum Klonen und, wenn Sie Zugriff haben, zum Übertragen verwenden können.

Wenn der Server keine Git-HTTP-Smart-Dienst-Antwort sendet, versucht der Git-Client, auf das einfachere Dumb HTTP-Protokoll zurückzufallen. Das Dumb-Protokoll erwartet, dass das Bare-Git-Repository wie normale Dateien vom Webserver bereitgestellt wird. Die Schönheit von Dumb HTTP liegt in der Einfachheit der Einrichtung. Grundsätzlich müssen Sie nur ein Bare-Git-Repository unter Ihrem HTTP-Dokumenten-Root platzieren und einen speziellen post-update-Hook einrichten, und Sie sind fertig (siehe Git Hooks). Zu diesem Zeitpunkt kann jeder, der auf den Webserver zugreifen kann, unter dem Sie das Repository platziert haben, auch Ihr Repository klonen. Um den Lesezugriff auf Ihr Repository über HTTP zu ermöglichen, tun Sie Folgendes:

Das ist alles. Der post-update-Hook, der standardmäßig mit Git geliefert wird, führt den entsprechenden Befehl (git update-server-info) aus, um HTTP-Abruf und Klonen korrekt zu machen. Dieser Befehl wird ausgeführt, wenn Sie in dieses Repository übertragen (vielleicht über SSH); dann können andere Personen über etwas wie Folgendes klonen:

In diesem speziellen Fall verwenden wir den Pfad /var/www/htdocs, der für Apache-Setups üblich ist, aber Sie können jeden statischen Webserver verwenden – platzieren Sie einfach das Bare-Repository in seinem Pfad. Die Git-Daten werden als einfache statische Dateien bereitgestellt (siehe das Kapitel Git Internals für Details, wie sie genau bereitgestellt werden).

Im Allgemeinen würden Sie entweder einen Lese-/Schreib-Smart-HTTP-Server betreiben oder die Dateien einfach im Dumb-Modus als schreibgeschützt zugänglich machen. Es ist selten, eine Mischung aus beiden Diensten zu betreiben.

Wir konzentrieren uns auf die Vorteile der Smart-Version des HTTP-Protokolls.

Die Einfachheit, eine einzige URL für alle Arten von Zugriff zu haben, und dass der Server nur dann zur Authentifizierung auffordert, wenn dies erforderlich ist, macht die Dinge für den Endbenutzer sehr einfach. Die Möglichkeit, sich mit Benutzername und Passwort zu authentifizieren, ist ebenfalls ein großer Vorteil gegenüber SSH, da Benutzer keine SSH-Schlüssel lokal generieren und ihren öffentlichen Schlüssel auf den Server hochladen müssen, bevor sie damit interagieren können. Für weniger anspruchsvolle Benutzer oder Benutzer auf Systemen, auf denen SSH weniger verbreitet ist, ist dies ein erheblicher Vorteil in Bezug auf die Benutzerfreundlichkeit. Es ist auch ein sehr schnelles und effizientes Protokoll, ähnlich dem SSH-Protokoll.

Sie können Ihre Repositories auch schreibgeschützt über HTTPS bereitstellen, was bedeutet, dass Sie die Inhaltsübertragung verschlüsseln können; oder Sie können bis zum Äußersten gehen und die Clients dazu bringen, spezifische signierte SSL-Zertifikate zu verwenden.

Ein weiterer Vorteil ist, dass HTTP und HTTPS so häufig verwendete Protokolle sind, dass Unternehmensfirewalls oft so eingerichtet sind, dass sie den Datenverkehr über ihre Ports zulassen.

Git über HTTPS kann auf einigen Servern etwas komplizierter einzurichten sein als SSH. Abgesehen davon gibt es sehr wenige Vorteile, die andere Protokolle gegenüber Smart HTTP für die Bereitstellung von Git-Inhalten haben.

Wenn Sie HTTP für die authentifizierte Übertragung verwenden, ist die Angabe Ihrer Anmeldedaten manchmal komplizierter als die Verwendung von Schlüsseln über SSH. Es gibt jedoch mehrere Tools zur Zwischenspeicherung von Anmeldeinformationen, die Sie verwenden können, darunter Keychain-Zugriff unter macOS und Credential Manager unter Windows, um dies ziemlich problemlos zu gestalten. Lesen Sie Credential Storage, um zu erfahren, wie Sie die sichere Zwischenspeicherung von HTTP-Passwörtern auf Ihrem System einrichten.

Die Vorteile der Verwendung von SSH sind zahlreich. Erstens ist SSH relativ einfach einzurichten – SSH-Daemons sind alltäglich, viele Netzwerkadministratoren haben Erfahrung mit ihnen, und viele Betriebssystemverteilungen sind mit ihnen eingerichtet oder haben Tools zu ihrer Verwaltung. Als nächstes ist der Zugriff über SSH sicher – die gesamte Datenübertragung ist verschlüsselt und authentifiziert. Zuletzt, ähnlich wie bei HTTPS, Git und lokalen Protokollen, ist SSH effizient und komprimiert die Daten so weit wie möglich, bevor sie übertragen werden.

Der negative Aspekt von SSH ist, dass er keinen anonymen Zugriff auf Ihr Git-Repository unterstützt. Wenn Sie SSH verwenden, *müssen* Personen SSH-Zugriff auf Ihre Maschine haben, selbst im schreibgeschützten Modus, was SSH nicht für Open-Source-Projekte geeignet macht, bei denen Leute Ihr Repository einfach nur klonen möchten, um es zu untersuchen. Wenn Sie es nur innerhalb Ihres Unternehmensnetzwerks verwenden, ist SSH möglicherweise das einzige Protokoll, mit dem Sie zu tun haben. Wenn Sie anonymen Lesezugriff auf Ihre Projekte ermöglichen möchten und auch SSH verwenden möchten, müssen Sie SSH für Ihre Übertragungen einrichten, aber etwas anderes für andere zum Abrufen.

Das Git-Protokoll ist oft das schnellste Netzwerkübertragungsprotokoll. Wenn Sie viel Verkehr für ein öffentliches Projekt bereitstellen oder ein sehr großes Projekt bereitstellen, das keine Benutzerauthentifizierung für den Lesezugriff benötigt, ist es wahrscheinlich, dass Sie einen Git-Daemon einrichten möchten, um Ihr Projekt bereitzustellen. Es verwendet denselben Datenübertragungsmechanismus wie das SSH-Protokoll, jedoch ohne den Overhead für Verschlüsselung und Authentifizierung.

Aufgrund des Mangels an TLS oder anderer Kryptografie kann das Klonen über git:// zu einer Schwachstelle für die Ausführung von beliebigem Code führen und sollte daher vermieden werden, es sei denn, Sie wissen, was Sie tun.

Es gibt auch keine Authentifizierung, d.h. jeder kann das Repository klonen (obwohl das oft genau das ist, was Sie wollen). Es ist auch wahrscheinlich das schwierigste Protokoll einzurichten. Es muss seinen eigenen Daemon ausführen, der eine xinetd- oder systemd-Konfiguration oder ähnliches erfordert, was nicht immer ein Spaziergang ist. Es erfordert auch Firewall-Zugriff auf Port 9418, der kein Standardport ist, den Unternehmensfirewalls immer zulassen. Hinter großen Unternehmensfirewalls wird dieser obskure Port häufig blockiert.