Q: You're setting up a Git server for an organization. What are the differences between the four transfer protocols Git supports (Local, HTTP, SSH, Git), and which would you choose?

Git supports four protocols for communication between client and server:

• Uses the filesystem directly. No network, no authentication beyond filesystem permissions.
• Fast, simple, but only works on the same machine or NFS mounts.
• Use case: shared server with SSH access where repos live on a mounted filesystem.
• Runs over standard HTTP(S) — passes through firewalls, proxies, and load balancers.
• Authentication via username/password, tokens, or SSO.
• Smart HTTP (default since Git 1.6.6) negotiates only needed objects — efficient as SSH.
• Recommended for most organizations — works everywhere, supports all auth methods, TLS for encryption.
• Encrypted, authenticated via SSH keys. No anonymous access possible.

1. Local protocol (file:// or just a path): 2. HTTP/HTTPS (Smart HTTP): 3. SSH: 4. Git protocol (git://): For a new organization: Smart HTTPS with token-based authentication (PATs or OAuth via SSO). It works through corporate proxies, supports granular permissions via the hosting platform, and uses TLS. SSH as a secondary option for developers who prefer it. Never use the raw Git protocol.

git clone /srv/git/repo.git

• Well-understood security model; keys can be centrally managed (LDAP, SSO-issued certificates).
• No built-in authorization granularity — you either have shell access or you don't. Tools like Gitolite or platform features (GitHub, GitLab) add per-repo/per-branch authorization on top.
• Best for: internal teams where everyone has SSH keys, and you want simplicity without HTTP infrastructure.
• Unauthenticated, unencrypted, read-only by convention. Runs on port 9418.
• Fastest protocol (no encryption overhead), but no security.
• Almost never used today. Was useful for public read-only mirrors; HTTPS has replaced it.