Introduzione

Git può trasportare dati su quattro famiglie di protocolli. Ognuna ha compromessi diversi in performance, autenticazione e amichevolezza con i firewall.

Locale / file

Clonare da una directory usa I/O di file locali. Due forme di URL:

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

La prima forma può usare hardlink per gli oggetti quando sullo stesso filesystem (molto veloce, molto efficiente in spazio). La forma file:// copia sempre via il protocollo smart.

SSH

Il default per workflow autenticati. Usa il tuo client SSH e la chiave:

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

Dietro le quinte, il client invoca ssh ed esegue git-upload-pack o git-receive-pack sul lato server. Configura le chiavi via ~/.ssh/config e ssh-agent.

HTTP / HTTPS

Più amichevole con i firewall e default per molti host:

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

Il protocollo HTTP smart usa POST /info/refs?service=git-upload-pack e endpoint simili. L'autenticazione è via Basic auth (deprecata in molti provider) o token nel campo password. Un credential helper evita prompt a ogni operazione:

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

git:// (anonimo)

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

Porta 9418, non autenticato, in chiaro. Perlopiù storico; non raccomandato per nuovi deployment perché non offre garanzie di integrità oltre agli hash di Git.

Versioni del protocollo

Il wire protocol ha v0, v1 e v2. Il protocollo v2 (Git 2.18+, default 2.26+) è drasticamente più veloce per repo con molti ref, perché il server pubblicizza solo i ref che il client ha richiesto.

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

Smart vs dumb

I protocolli "smart" negoziano; il "dumb" HTTP espone solo la directory .git/. L'HTTP dumb richiede git update-server-info a ogni push ed è più lento; quasi nessuno lo usa oggi.

Scegliere un protocollo

• HTTPS: il più facile da configurare, funziona ovunque, buono per read-only e CI.
• SSH: il migliore per push/pull quotidiani quando controlli la tua chiave.
• file://: comodo per mirror locali e test.
• git://: evita tranne che per mirror pubblici estremamente permissivi.

Negoziazione delle capabilities

Al momento della connessione, client e server scambiano capabilities (multi-ack, side-band, ofs-delta, filter, partial clone, push-options, atomic, ecc.). Le capabilities supportate determinano quali funzionalità l'operazione può usare. Ispeziona con il packet tracing:

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

I server più vecchi possono non supportare capabilities più nuove; il client ricade con grazia. Se vedi clone o fetch sorprendentemente lenti, un server vecchio che manca di multi-ack-detailed o filter è spesso la causa.

Errori comuni

Mescolare URL HTTPS e SSH nello stesso repo; se una CI usa HTTPS ma il tuo dev usa SSH, gli script possono confondere l'uno con l'altro. O attieniti a uno o usa la riscrittura insteadOf:

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

Memorizzare personal access token in config in chiaro; usa invece un credential helper. Dimenticare di abilitare protocol.version=2 su installazioni Git vecchie. Infine, esporre git:// sulla rete aperta per accesso in scrittura; il protocollo non può autenticare. Usa SSH o HTTPS.