Linux

The Linux Kernel on GitHub: What It Really Is

Search "Linux kernel github" and you'll land on a repository with hundreds of thousands of stars — but it's not where kernel development actually happens. Here's the full story, and exactly how to get the source yourself.

If you've ever typed "Linux kernel github" into a search bar, you've probably found github.com/torvalds/linux — a repo with well over 180,000 stars and a contributor list that reads like a who's who of systems programming. It looks like the center of the universe for Linux development. It isn't. It's a mirror, and understanding that distinction tells you almost everything about how the kernel is actually built.

This article walks through what that GitHub repository really is, where the kernel's true source tree lives, how to clone it without burning a hundred gigabytes of disk space, and how to navigate the source once you have it. If you've ever wanted to read or build the actual code that runs on billions of devices, this is your map.

The GitHub repo is a read-only mirror

Let's clear up the single most common misconception first. The repository at github.com/torvalds/linux is Linus Torvalds' personal mirror of the kernel tree. It's genuinely his — pushed to by him — but it is not where patches get submitted, reviewed, or merged. You cannot send a pull request to that repo and expect it to be reviewed. In fact, the kernel project explicitly tells people not to.

The reason is cultural and technical at once. Linux kernel development predates GitHub by years and runs on a workflow that GitHub's pull-request model simply doesn't accommodate. Changes flow through mailing lists as plain-text patches, get reviewed inline, get picked up by subsystem maintainers, and eventually bubble up to Linus through a tree of trust relationships. The GitHub mirror exists so people can browse, clone, and star — not contribute.

Where the real Linux kernel source lives

The canonical home of the kernel is git.kernel.org, hosted by the Linux Foundation on infrastructure the community controls. The mainline tree maintained by Linus sits at:

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git — the mainline tree
• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git — the stable tree maintained by Greg Kroah-Hartman

There are hundreds of other trees on kernel.org too — one per subsystem maintainer, plus -next integration trees and various experimental branches. This decentralization is the whole point. Git itself was created by Torvalds in 2005 precisely because the kernel needed distributed version control after the BitKeeper licensing fallout. The kernel and Git grew up together, which is part of why the project never depended on any single hosting platform. If you want the broader context of how this ecosystem is governed, the Linux Foundation's role in open source projects is worth understanding — the kernel is the crown jewel of that umbrella.

So when people ask about the "Linux kernel repo" or the "Linux kernel source tree," the honest answer is: there isn't one repo. There's a mainline and an entire forest of trees that feed into it. The GitHub mirror flattens that complexity into something familiar, which is exactly why it ranks so well in search.

How to git clone the Linux kernel

Cloning the kernel is straightforward, but the full history is enormous — the complete repository with all branches and tags runs well past 5 GB, and a checked-out working tree adds a few more. The full Git history goes back to 2005 and contains over a million commits. Here's the standard clone from kernel.org:

• git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Or, if you prefer the GitHub mirror for speed or familiarity:

• git clone https://github.com/torvalds/linux.git

Both give you the same source. If you're on a metered connection or just want to read the latest code without decades of history, do a shallow clone — this pulls only the most recent commit and is dramatically smaller and faster:

• git clone --depth=1 https://github.com/torvalds/linux.git

A --depth=1 clone can finish in a couple of minutes on a decent connection versus 20+ minutes for the full history, and it'll occupy roughly 1.5 GB instead of 5+. The tradeoff is that you lose git log history and the ability to git bisect across older releases — fine for browsing, not for serious development. If you later need the full history, git fetch --unshallow backfills it.

Just want to download a release, not clone?

If you don't need Git at all and just want a specific kernel version — the "Linux kernel download" use case — go to kernel.org directly. The front page lists the current mainline, stable, and longterm releases as compressed tarballs (.tar.xz). Grabbing linux-6.12.tar.xz and extracting it gives you a clean source tree without any Git metadata, which is often what distribution packagers and people building a one-off custom kernel actually want. GitHub also offers the same thing under the "Releases" or by appending the tag to an archive URL, but kernel.org is the authoritative source and includes the PGP signatures to verify integrity.

Reading the source tree: a quick orientation

Once you've cloned it, the top-level directory layout is the same whether you got it from GitHub or kernel.org. Here's where the important things live:

• kernel/ — the core: scheduler, signals, time management, the heart of the system
• mm/ — memory management, including the page allocator and virtual memory
• fs/ — every filesystem the kernel supports, from ext4 to Btrfs to NFS
• drivers/ — by far the largest directory; the vast majority of kernel code is device drivers
• net/ — the networking stack, TCP/IP and everything around it
• arch/ — architecture-specific code, one subdirectory per CPU family (x86, arm64, riscv, etc.)
• include/ — header files defining the kernel's internal and user-facing APIs
• Documentation/ — genuinely excellent, often-ignored docs covering coding style, subsystems, and the contribution process

If you only browse one file, make it Documentation/process/submitting-patches.rst. It's the most concise explanation of how the project actually works, and it'll cure you of any illusion that GitHub pull requests are the way in. For a friendlier high-level tour of the source structure, It's FOSS published a readable breakdown of the kernel and how it fits into a Linux system that pairs well with poking around the tree yourself.

About those "Linux kernel github issues"

People search for kernel GitHub issues hoping to report a bug. Don't bother on the mirror — issues there are not monitored by maintainers and pull requests are routinely closed unread. The real bug tracker is bugzilla.kernel.org, though even that is uneven; many subsystems prefer bug reports sent straight to their mailing list, with the relevant maintainer CC'd. You find the right maintainer by running the scripts/get_maintainer.pl tool included in the source tree against the file you're concerned about:

• ./scripts/get_maintainer.pl drivers/net/ethernet/intel/e1000e/

That script reads the MAINTAINERS file and tells you exactly who to email and which list to copy. It's a small thing, but it captures the spirit of kernel development: distributed, email-driven, and built on knowing whose tree your change belongs in.

Should you actually clone the kernel?

Here's my honest take after years around this code. For most people the answer is no — you don't need to clone 5 GB of source to use, run, or even tinker with Linux. If you're learning the system, your time is far better spent getting comfortable in a terminal first; our rundown of the essential commands every beginner should know is a more practical starting point than reading scheduler internals.

But if any of the following describe you, cloning is genuinely worth it:

• You're studying systems programming. There's no better-documented, more battle-tested codebase to read. Grep for a syscall and trace it through. It's an education.
• You need a custom kernel. Maybe you're enabling an obscure driver, patching for a specific NIC, or tuning for low latency. Cloning, configuring with make menuconfig, and building is the path.
• You want to contribute. Then start by reading the docs, subscribing to the relevant subsystem list, and submitting your first trivial patch the right way.

For everyone else, browsing on GitHub is plenty. The web interface lets you search the entire tree, read commit history, and follow the firehose of changes Linus merges every release cycle without downloading anything.

The bigger picture: why this matters

The fact that "Linux kernel github" is such a popular search — while the real development happens on mailing lists and kernel.org — is a neat illustration of the gap between how open source is perceived and how it actually operates. GitHub has become the default mental model for "where code lives," and the kernel deliberately doesn't fit that model. It predates it, outscales it, and answers to no single platform.

That independence is a feature, not an accident. The kernel can't afford to depend on a corporate-owned platform for its survival, so it doesn't. The GitHub mirror is a courtesy to the world, not a dependency. Understanding that distinction puts you ahead of most people who think starring a repo is the same as understanding a project.

Where to go from here

If reading kernel internals has you curious about running Linux more seriously, the natural next steps are practical. You can install a distro and follow our step-by-step guide, or weigh whether the switch is right for you with our take on Linux versus Windows in 2026. The kernel is the foundation, but the distribution is what you actually live in day to day.

And if you do clone the tree, give yourself permission to just read. Open kernel/sched/core.c, scroll, and accept that you won't understand all of it on the first pass — nobody did. The Linux kernel is one of the largest collaborative engineering efforts in human history, with tens of thousands of contributors across four decades of accumulated knowledge. The GitHub mirror is simply the most visible doorway into it. Now you know it's a window, not a door — and where the real door is.