Introduction

Git peut transporter des données sur quatre familles de protocoles. Chacun a différents compromis en performance, authentification et compatibilité avec les pare-feu.

Local / file

Cloner depuis un répertoire utilise les E/S locales. Deux formes d'URL :

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

La première forme peut utiliser des hardlinks pour les objets sur le même système de fichiers (très rapide, très efficace en espace). La forme file:// copie toujours via le smart protocol.

SSH

Le défaut pour les workflows authentifiés. Utilise votre client SSH et votre clé :

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

Dans les coulisses, le client invoque ssh et exécute git-upload-pack ou git-receive-pack côté serveur. Configurez les clés via ~/.ssh/config et ssh-agent.

HTTP / HTTPS

Le plus compatible avec les pare-feu et le défaut pour de nombreux hôtes :

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

Le smart HTTP utilise POST /info/refs?service=git-upload-pack et endpoints similaires. L'authentification est via Basic auth (déprécié chez de nombreux fournisseurs) ou token dans le champ mot de passe. Un assistant d'identifiants évite les invites à chaque opération :

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

git:// (anonyme)

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

Port 9418, non authentifié, en clair. Surtout historique ; non recommandé pour de nouveaux déploiements parce qu'il n'offre aucune garantie d'intégrité au-delà des hachages propres de Git.

Versions de protocole

Le protocole filaire a v0, v1 et v2. Le protocole v2 (Git 2.18+, défaut 2.26+) est dramatiquement plus rapide pour les dépôts avec de nombreuses refs, parce que le serveur n'annonce que les refs demandées par le client.

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

Smart vs dumb

Les protocoles « smart » négocient ; le HTTP « dumb » expose simplement le répertoire .git/. Le HTTP dumb nécessite git update-server-info à chaque push et est plus lent ; presque personne ne l'utilise aujourd'hui.

Choisir un protocole

• HTTPS : le plus facile à configurer, fonctionne partout, bon pour la lecture seule et la CI.
• SSH : le meilleur pour push/pull quotidien quand vous contrôlez votre clé.
• file:// : pratique pour les miroirs locaux et les tests.
• git:// : à éviter sauf pour les miroirs publics extrêmement permissifs.

Négociation de capacités

Au moment de la connexion, le client et le serveur échangent des capacités (multi-ack, side-band, ofs-delta, filter, partial clone, push-options, atomic, etc.). Les capacités supportées déterminent quelles fonctionnalités l'opération peut utiliser. Inspectez avec le traçage de paquets :

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

Les serveurs plus anciens peuvent ne pas supporter les capacités plus récentes ; le client retombe gracieusement. Si vous voyez des clones ou fetches étonnamment lents, un vieux serveur sans multi-ack-detailed ou filter en est souvent la cause.

Erreurs fréquentes

Mélanger HTTPS et SSH dans le même dépôt ; si une CI utilise HTTPS mais votre dev utilise SSH, les scripts peuvent se confondre. Soit tenez-vous-en à un seul, soit utilisez la réécriture insteadOf :

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

Stocker des tokens d'accès personnels en clair dans la configuration ; utilisez plutôt un assistant d'identifiants. Oublier d'activer protocol.version=2 sur les vieilles installations Git. Enfin, exposer git:// sur l'Internet ouvert pour l'accès en écriture ; le protocole ne peut pas authentifier. Utilisez SSH ou HTTPS.