就个人而言，如果我用gitk查看git或linux repo，我会被大量的合并/分支所震撼。我完全不知道发生了什么。
我认为通常你会尝试在 public repo中创建一个尽可能线性的历史记录，并且只有一些分支（例如master，maint，next，pu - that it）。即我假设合并很少，大多数都使用rebase。显然我错了。
答案 0 :(得分：3)
在与Git和rebase的关系中要理解一件非常重要的事情。
Do not rebase commits that you have pushed to a public repository.
在您在本地进行合并期间，您可以根据需要随时使用rebase，因为它是本地的。如果你喜欢线性的历史。换句话说，你不会看到他们所做的rebase工作。
关于分支数量的另一部分只是一种体验，而不仅仅是一个概念问题。我已经完成了300多个并行分支的分支。这只是通过使用约定和一个好的概念来驯服野兽。
答案 1 :(得分：2)
我不是内核开发人员，当然不能代表他们。 Here's一个参考，其中Linus谈到了一些，我认为回答你的问题。我将补充说，有很多随机分支令人困惑，但对它强加一点订单会使更容易拥有分支IMHO。 （顺序的示例可能是将主题分支命名为topic/short_name，包括有意义的提交消息，开发人员保留一些外部文档并实际相互通信，或者适合您的环境的任何内容。）
我还会提及对this工作流程的引用，因为它实际上需要Git阅读，并适用于您的问题。
答案 2 :(得分：0)
请记住，当您克隆git仓库时，您可能会获得所有远程分支，但您只需创建并签出一个本地分支（通常为master，跟踪{{1 }}）
（这就是为什么你有“Track all remote git branches as local branches”）
之类的问题根据您感兴趣的主题，您只需结帐并跟踪一个特定分支，执行一些工作，并定期在remotes/origin/master之上重新定位您的本地分支，以使您的工作保持最新状态。
您不会从官方公共分支机构合并到您的分支机构：这将是一个反向合并，应该避免它们，如“What is the right git workflow with shared feature branches?”中所示。
答案 3 :(得分：0)
查看Greg K-H Ask a kernel developer专栏：他详细解释了他的工作流程。 Greg曾经是稳定分支的维护者;他是许多子系统的当前维护者，包括USB。