6

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?
Rafał Rawicki
  • 22,324
  • 5
  • 59
  • 79
Florian Kaufmann
  • 803
  • 6
  • 13
  • Branches are cheap so they are taken advantage of often :) – Nic Apr 01 '12 at 16:28
  • In 2007 [Google Tech Talk](https://www.youtube.com/watch?v=4XpnKHJAok8) Linus Torvalds gives some examples of how he uses git, particularly on kernel and git itself. – andrybak Oct 18 '15 at 11:04

4 Answers4

3

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.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
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.

rob
  • 2,053
  • 15
  • 13
0

Remember that, when you are cloning a git repo, you may get all the remote branches, but you only create and checkout one local branch (usually master, tracking remotes/origin/master)

(This is why you have questions like "Track all remote git branches as local branches")

Depending on your topic of interest, you would only checkout and track one specific branch, do some work, and rebase regularly your local branch on top of origin/branch to keep your work up-to-date.

You won't merge from the official public branches to your branch: that would be a back-merge, and they should be avoided, as illustrated in "What is the right git workflow with shared feature branches?".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Check out Greg K-H Ask a kernel developer column: he explains his workflow in detail. Greg used to be the maintainer of the stable branch; he is the current maintainer for many subsystems, including USB.

alexfernandez
  • 1,938
  • 3
  • 19
  • 30