Why Does the Linux Kernel Repository Have Only One Branch

Why does the Linux kernel repository have only one branch?

Mainline kernel

First of all: don't use that github link (it's just a mirror). The actual repositories are located at kernel.org. You probably want to use Linus Torvalds' tree, which is torvalds/linux.git.

It's called mainline kernel, which means this tree is the one where actual development of next kernel version is happening. Although it has only master branch, you can checkout to any kernel version using tags. This command will show you all version tags:

$ git tag

You can checkout to desired tag like that:

$ git checkout v4.0

There is no need in a bunch of branches for mainline kernel, as development process in this tree never stops, and once new version is released, there won't be any back-porting to that version (inside mainline tree). So Linus sticks to tags (instead of branches) in this case.

Stable kernel

There is also linux-stable tree. "Stable" means that after release, some bug fixes would be back-ported to it. In this tree you should look for branches (rather than tags):

$ git branch -a

You can see branches like:

linux-4.9.y

where y suffix is just a placeholder for a bugfix version (because naming scheme is linux-4.x.y). Whenever you see y suffix -- it's a stable kernel branch. Some of those branches are LTS kernels (read this for details).

In this case branches are needed because developers have to backport some bug fixes into released versions. So just tags are not enough here.

Next kernel

It also should be mentioned that there is linux-next tree. Here is the description from kernel process documentation:

Before updates from subsystem trees are merged into the mainline 4.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis:

https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

This way, the -next kernel gives a summary outlook onto what will be expected to go into the mainline kernel at the next merge period. Adventurous testers are very welcome to runtime-test the -next kernel.

Maintainer trees

Back to the trees. Actually there are many of them, they are called maintainers trees. You can see all of them here.

You need to understand merging policy: only Linus can actually merge code to the mainline tree. You can see a lot of merge commits from him in git log. So if you want your patch to be applied to mainline kernel, you need to send it to kernel mailing lists for review first. See Documentation/SubmittingPatches. Once your patch is reviewed and acknowledged by corresponding subsystem maintainer, he will apply it to his own tree. From there this patch will be merged to mainline kernel during next merge window. Linux kernel development model is described here.

If you are interested in upstreaming your patches -- you may also want to go through kernelnewbies.org materials.

Why are there no branches in Linux kernel source code?

As people said in the comments, it is not because there is only a master branch that there are no branches on local clones and other forks. The contributions don't necessarily pass via Github, and if you have a look at the commits log and crunch numbers, you will see that there are a lot of branch merges:

> git log --oneline --merges | egrep "Merge (branch|tag)" | wc -l
50914

On big public projects, it is probably a better idea to keep the main repository as mirror/reference and if you want to develop on in, you fork it. From here, you do what you want on it, create the branches you want, and when ready, push a contribution request via the project's favourite medium (PR, mail...). And when new changes are introduced in the project's master, the main repository is updated to get the change.

Kernel building: how are the torvalds and stable repos related?

Yes, you'd mostly want to build off stable unless you're working on bleeding-edge stuff.

Tags are merely pointers to commits - just because one repo has a tag and the other doesn't doesn't mean that the commit isn't present in both repos. (For instance, 'stable' could have a tag 'Foo' that points to commit 'A' - torvalds might also have that commit A as part of some branches, but doesn't have the named tag.)

Git: how can git/linux maintainers maintain so many branches

There one very important thing to understand in relationship with Git and rebase.

Do not rebase commits that you have pushed to a public repository.

During the time you are working on a merge locally you can use rebase as much often as you like, cause it's local. If you like a linear histroy. In other words you won't see the rebase work they did.

The other part about the number of branches is simply a kind of experience and more than that a question of concept. I have done branching with over 300 branches in parallel..which is only a kind taming the beast by using conventions and a good concept.

---

Related Topics