Introducción

Git puede transportar datos sobre cuatro familias de protocolos. Cada uno tiene diferentes compromisos en rendimiento, autenticación y amabilidad con firewalls.

Local / file

Clonar desde un directorio usa I/O de archivo local. Dos formas de URL:

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

La primera forma puede usar hardlinks para los objetos cuando están en el mismo sistema de archivos (muy rápido, muy eficiente en espacio). La forma file:// siempre copia vía el protocolo smart.

SSH

El predeterminado para flujos autenticados. Usa tu cliente SSH y clave:

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

Detrás de escena, el cliente invoca ssh y ejecuta git-upload-pack o git-receive-pack en el lado del servidor. Configura claves vía ~/.ssh/config y ssh-agent.

HTTP / HTTPS

El más amigable con firewalls y predeterminado para muchos hosts:

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

El protocolo HTTP smart usa POST /info/refs?service=git-upload-pack y endpoints similares. La autenticación es vía Basic auth (deprecada en muchos proveedores) o token en el campo de contraseña. Un asistente de credenciales evita prompts en cada operación:

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

git:// (anónimo)

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

Puerto 9418, no autenticado, texto plano. Mayormente histórico; no recomendado para nuevos despliegues porque no ofrece garantías de integridad más allá de los hashes propios de Git.

Versiones de protocolo

El protocolo de cable tiene v0, v1 y v2. El protocolo v2 (Git 2.18+, predeterminado 2.26+) es dramáticamente más rápido para repos con muchas refs, porque el servidor solo anuncia las refs que el cliente solicitó.

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

Smart vs dumb

Los protocolos "smart" negocian; el HTTP "dumb" solo expone el directorio .git/. El HTTP dumb requiere git update-server-info en cada push y es más lento; casi nadie lo usa hoy.

Eligiendo un protocolo

• HTTPS: el más fácil de configurar, funciona en todas partes, bueno para solo lectura y CI.
• SSH: el mejor para push/pull diario cuando controlas tu clave.
• file://: conveniente para mirrors locales y tests.
• git://: evítalo excepto para mirrors públicos extremadamente permisivos.

Negociación de capacidades

Al momento de la conexión, el cliente y el servidor intercambian capacidades (multi-ack, side-band, ofs-delta, filter, partial clone, push-options, atomic, etc.). Las capacidades soportadas determinan qué características puede usar la operación. Inspecciona con tracing de paquetes:

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

Los servidores antiguos pueden no soportar capacidades más nuevas; el cliente cae con elegancia. Si ves clones o fetches sorprendentemente lentos, un servidor antiguo carente de multi-ack-detailed o filter es a menudo la causa.

Errores comunes

Mezclar URLs HTTPS y SSH en el mismo repo; si un CI usa HTTPS pero tu desarrollo usa SSH, los scripts pueden confundirse entre sí. O bien apégate a uno o usa reescritura insteadOf:

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

Almacenar tokens de acceso personal en config en texto plano; usa un asistente de credenciales en su lugar. Olvidar habilitar protocol.version=2 en instalaciones de Git antiguas. Finalmente, exponer git:// en el internet abierto para acceso de escritura; el protocolo no puede autenticar. Usa SSH o HTTPS.