http://www.linuxfoundation.org/content/how-participate-linux... is a reasonable overview of the development process, as is the canonical SubmittingPatches (
https://www.kernel.org/doc/Documentation/SubmittingPatches)
A very quick overview:
* Linus Torvalds is the only person who can commit code to Linux mainline.
* Individual subsystem maintainers maintain their own git trees, e.g. https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.g....
* Patches are emailed to subsystem mailing lists (using git send-email, usually), reviewed by the community, and potentially resubmitted a few times to respond to community feedback. (There is also the infamous Linux Kernel Mailing List which is generally used for patches that have wider effects, new drivers, stuff that doesn't fall neatly into a subsystem...) Often tracked using tools like Patchwork (e.g. http://patchwork.ozlabs.org/)
* As a result of this, each individual developer generally maintains a tonne of branches for themselves - they work independently of anyone else.
* Kernel has quite strict requirements for how patches/commits are formatted - as per SubmittingPatches
* Maintainers apply patches to their own tree (potentially with their own modifications if needed). They often use a structure like a "next" branch for patches intended for the next release cycle, and a "fixes" branch for bugfixes which can be included in the next RC release.
* Maintainers generally email a pull request (git request-pull) to Linus when they want changes merged. Linus reviews and ACKs/NAKs them.
* Linus will only accept new features during the 2 week "merge window" that immediately follows each new kernel version. Following the merge window, rc1 is released, and from then a new rc is released every week until rc7 or rc8 (at Linus' discretion) - only bugfixes or very minor things accepted during this time.
* In the meantime, each maintainer has their own git tree, and someone has to try to integrate them together for testing purposes. That someone is Stephen Rothwell, who merges everyone's -next branches 5 days a week and releases linux-next (http://git.kernel.org/cgit/linux/kernel/git/next/linux-next....) as a snapshot of what the next kernel release will look like.
So there's quite little centralised infrastructure involved in this process apart from a few things on kernel.org. There's ~1500 developers involved in each kernel release across dozens of companies. As you can probably guess, there's a lot of cherry-picking, rebasing, and so on involved in all this.