Einführung

Git kann Daten über vier Protokollfamilien transportieren. Jede hat unterschiedliche Abwägungen in Bezug auf Performance, Authentifizierung und Firewall-Freundlichkeit.

Local / file

Klonen aus einem Verzeichnis verwendet lokale Datei-I/O. Zwei URL-Formen:

git clone /srv/git/widget.git
git clone file:///srv/git/widget.git

Die erste Form kann Hardlinks für Objekte verwenden, wenn auf demselben Dateisystem (sehr schnell, sehr platzsparend). Die file://-Form kopiert immer über das Smart-Protokoll.

SSH

Der Standard für authentifizierte Workflows. Verwendet Ihren SSH-Client und Schlüssel:

git clone [email protected]:example/widget.git
git clone ssh://[email protected]/example/widget.git

Hinter den Kulissen ruft der Client ssh auf und führt git-upload-pack oder git-receive-pack auf der Server-Seite aus. Konfigurieren Sie Schlüssel via ~/.ssh/config und ssh-agent.

HTTP / HTTPS

Am firewall-freundlichsten und der Standard für viele Hosts:

git clone https://github.com/example/widget.git

Das Smart-HTTP-Protokoll verwendet POST /info/refs?service=git-upload-pack und ähnliche Endpunkte. Authentifizierung erfolgt über Basic Auth (bei vielen Anbietern deprecated) oder Token im Passwortfeld. Ein Credential-Helper vermeidet Eingabeaufforderungen bei jeder Operation:

git config --global credential.helper cache
git config --global credential.helper osxkeychain   # macOS
git config --global credential.helper manager       # Windows

git:// (anonym)

git clone git://example.com/widget.git

Port 9418, unauthentifiziert, im Klartext. Größtenteils historisch; nicht empfohlen für neue Deployments, weil es keine Integritätsgarantien über Gits eigene Hashes hinaus bietet.

Protokollversionen

Das Wire-Protokoll hat v0, v1 und v2. Protokoll v2 (Git 2.18+, Standard 2.26+) ist für Repositories mit vielen Refs dramatisch schneller, weil der Server nur Refs ankündigt, die der Client angefragt hat.

git -c protocol.version=2 ls-remote origin
git config --global protocol.version 2

Smart vs. dumm

"Smart"-Protokolle verhandeln; "dummes" HTTP stellt einfach das .git/-Verzeichnis bereit. Dummes HTTP erfordert git update-server-info bei jedem Push und ist langsamer; nahezu niemand verwendet es heute.

Ein Protokoll wählen

• HTTPS: am einfachsten einzurichten, funktioniert überall, gut für Read-Only und CI.
• SSH: am besten für tägliches Push/Pull, wenn Sie Ihren Schlüssel kontrollieren.
• file://: bequem für lokale Mirrors und Tests.
• git://: außer für extrem permissive öffentliche Mirrors meiden.

Capability-Verhandlung

Beim Verbindungsaufbau tauschen Client und Server Capabilities aus (multi-ack, side-band, ofs-delta, filter, partial clone, push-options, atomic usw.). Unterstützte Capabilities bestimmen, welche Funktionen die Operation nutzen kann. Inspizieren Sie mit Paket-Tracing:

GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote origin 2>&1 | head -40

Ältere Server unterstützen möglicherweise neuere Capabilities nicht; der Client weicht elegant aus. Wenn Sie überraschend langsame Klone oder Fetches sehen, ist ein alter Server, dem multi-ack-detailed oder filter fehlt, oft die Ursache.

Häufige Fehler

HTTPS- und SSH-URLs im selben Repository mischen; wenn ein CI HTTPS verwendet, Ihre Dev-Umgebung aber SSH, können Skripte einander verwirren. Bleiben Sie entweder bei einem oder verwenden Sie insteadOf-Umschreibung:

git config --global url."[email protected]:".insteadOf "https://github.com/"

Personal Access Tokens im Klartext-Konfig speichern; verwenden Sie stattdessen einen Credential-Helper. Vergessen, protocol.version=2 auf alten Git-Installationen zu aktivieren. Schließlich: git:// auf dem offenen Internet für Schreibzugriff bereitstellen; das Protokoll kann nicht authentifizieren. Verwenden Sie SSH oder HTTPS.