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

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.

  • How to check in git to which branch was the last change made?
  • Git: Teamwork across branches without Push Permission
  • git / gerrit prevent develop branch to be merged into stable / testing branch
  • Keeping a public and private version of my app using Git
  • How to only merge changes added after a certain revision (both ways)?
  • Merging two branches into one another
    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?

  • How to create a Git Tag using GitExtensions for Windows?
  • How to hide the access keys of aws amazon productively in VagrantFile file
  • EC2 can't SSH into github
  • Managing Temporary Files Created by an IDE in Git
  • How to pull after a forced git push?
  • Git status shows local branch ahead by X commits - should only be 1
  • 4 Solutions collect form web for “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.

    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.

    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?”.

    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.

    Git Baby is a git and github fan, let's start git clone.