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.
- I wonder what the git/linux maintainers do to have a good easy overview
- Why don’t they use rebase more often and have much more branches than only master, maint, next pu?
There one very important thing to understand in relationship with Git and rebase.
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.