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

Question

Personally, if I look at the git or the linux repo with gitk, I am totally overwhelmed by the huge amount of merges/branched. I have absolutely no clue what is going on.

I assumed that in general you try to have an as linear history as possible and only a few branches (e.g. master, maint, next, pu - thats it) in the public repo. I.e. I assumed that merges are seldom and mostly rebase is used. Apparently I am wrong.

1. I wonder what the git/linux maintainers do to have a good easy overview
2. Why don't they use rebase more often and have much more branches than only master, maint, next pu?

Answer 1

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.

Answer 2

I am not a kernel developer, and certainly can not speak for them. Here's a reference where Linus talked about it some, that I think answers your questions. I will add that having lots of random branches is confusing, but imposing a little order on it makes it easier to have branches IMHO. (Examples of order might be naming topic branches as topic/short_name, including meaningful commit messages, devs keep some external documentation and actually talk to each other, or whatever is appropriate for your environment.)

I'll also include a reference to this workflow, since it is practally required Git reading, and applies to your question.