Ask most developers what GitHub is, and you will hear a deceptively straightforward answer:
"GitHub is a cloud hosting service for Git repositories with a web interface for code reviews and issue tracking."
If you only interact with GitHub through git push origin main and web pull requests, that description seems entirely accurate. You push your commits to a remote server, GitHub stores them, and your team inspects the diffs on a web page.
Yet running a platform that hosts over 100 million developers and more than 420 million repositories presents engineering hurdles that standard Git was never designed to handle:
What happens when 50,000 developers fork the Linux kernel or React? If GitHub stored 50,000 duplicate copies of a 4GB Git history, a single repository network would consume 200 terabytes of storage. Git was written as a local command-line tool, not a distributed network database. How does GitHub prevent data loss when hard drives fail or servers crash mid-push? How does GitHub compute whether a Pull Request can be merged without checking out files onto a disk? How does GitHub Actions spin up millions of clean, isolated virtual machines every hour, execute untrusted user code, and allow workflows to authenticate with AWS and Google Cloud without storing a single static password?
GitHub is not a single server running git-daemon. It is an enormous, highly specialized distributed operating system.
Here is what actually happens under the hood across GitHub's infrastructure when you push code, open a pull request, and trigger an automated build. The Git Storage Tier: How Spoke Clusters Shard the World
Standard Git relies on simple file system locking. When you push to a bare Git repository on an ordinary Linux server, Git runs git receive-pack. It checks if .git/refs/heads/main.lock exists, updates the reference, writes new packfiles, and releases the lock.
If two developers push simultaneously to the same branch on a standard Git server, one will fail. If the disk holding .git dies, your data is gone unless you have an offline backup.
To scale across hundreds of petabytes of Git data, GitHub built Spokes (formerly known as DGit, or Distributed Git).
In GitHub's architecture, repositories do not live on arbitrary file systems. They reside on dedicated, bare-metal storage servers called Spokes nodes.
Every repository is assigned to a cluster of three distinct Spokes file servers:
When you run git push origin main, your traffic hits GitHub's edge network over HTTPS or SSH. GitHub's routing layer (the Spokes proxy) authenticates your session and routes your Git RPC traffic directly to the repository's active primary storage node.
To guarantee that your push never gets lost or split, Spokes coordinates writes using a two-phase transactional consensus protocol: Pre-Receive Validation: The primary node receives your incoming packfile over the network. It calculates the checksums and verifies that all referenced parent commits exist in the object graph. Parallel Replication: Before updating any branch pointers, the primary streams the raw packfile data simultaneously to the two replica nodes. Quorum Acknowledgment: Once at least two of the three nodes confirm they have written the objects to disk and verified their SHA integrity, the primary acquires the reference lock. Pointer Commit: The branch reference (e.g., refs/heads/main) is atomically updated across the quorum. Success Response: Only after quorum is achieved does your local terminal print To github.com:user/repo.git [new branch].
If a hard drive explodes or a storage server loses power mid-push, the Spokes cluster detects the heartbeat failure within seconds. A replica with verified data is promoted to primary, a new third replica is provisioned in the background, and your repository remains online with zero data loss. Fork Networks: The Magic of Git Object Alternates
A project like the Linux kernel contains over 1.2 million commits and consumes roughly 4.5 gigabytes of disk space. As of today, it has over 50,000 public forks on GitHub.
If GitHub treated every fork as an independent Git repository, storing those forks would require:
Multiply that across React, Kubernetes, TensorFlow, and VS Code, and GitHub's storage costs would be astronomical.