企业 Linux 内核开发的 Git 工作流程

Question

我在一家使用 Linux 构建嵌入式系统的公司工作。从历史上看，我们一直使用 CVS 来存储我们的内核工作。我们的内核最终成为以下内容的集合:

• 我们专有硬件的驱动程序
• 随机修复我们使用的 Linux 部分
• 非专有硬件驱动程序
• 为我们的应用定制 Linux 的随机 yukky hack

我们正处于这样一个阶段，我们希望将一些较旧的内核重新定位到较新的版本上，并将我们陈旧的 CVS 工作流程修复为基于变更集的东西。显而易见的选择是 git。

我正在努力想出一个合理的工作流程。我已经为我们的一个内核导出了我们的 CVS 存储库，并且在适当的基本 Linus 内核之上有一组变更集。我从这里去哪里？

我想要一个中央存储库，供所有开发人员提交更改。使用 rebase 将我们的变更集集合向前移动到新的基本内核修订版然后让我们的开发在新的中央分支之上进行是否安全？

获得工作流的加分项使我们能够轻松分离出可能适合上游的更改。我受够了一直 push 一系列小的(或微小的)通常有用的更改。

Answer 1

Rebase 适用于 integrating upstream branches进入自己的本地分支，前提是不推送所述本地分支(因为该本地分支的历史已被重写)。参见例如 "git workflow and rebase vs merge questions" .

每个开发人员 Git 存储库中都应该有一个专用的“公共(public)”分支(即要推送的分支)，以便 merge/cherry-pick相关改动推送。
如果需要，多个公共(public)分支可能会共存，每个内核版本一个以维护/修复。

然后可以设置中央存储库以集成(即 pull )所有 push 其中的开发人员分支。

另见 "git releases management"有关 merge 工作流程和发布主题的更多信息。