用于企业 Linux 内核开发的 Git 工作流程 [英] Git workflow for corporate Linux kernel development

问题描述

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

I work for a company which builds embedded systems using Linux. Historically we've always used CVS to store our kernel work. Our kernels end up being a collection of:

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

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

We're at the stage where we would like to rebase some of our older kernels on newer versions as well as fixing up our archaic CVS workflow to something based on changesets. The obvious choice is git.

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

I'm struggling to come up with a sensible workflow. I have exported our CVS repository for one of our kernels and have a collection of changesets on top of the appropriate base Linus kernel. Where do I go from here?

我想要一个所有开发人员都可以提交更改的中央存储库.使用 rebase 将我们的变更集集合转移到新的基础内核修订版，然后在新的中央分支上进行开发是否安全?

I'd like to have a central repository that all developers commit changes to. Is it safe to use rebase to move our collection of changesets forward to a new base kernel revision and then have our developments be carried out on top of the new central branch?

获得工作流程的奖励积分，该工作流程使我们能够轻松分离出可能适合上游的更改.我厌倦了一直推动一系列小的(或微小的)普遍有用的变化.

Bonus points for getting a workflow that allows us to easily separate out changes that might be suitable for upstream. I'm fed up pushing a collection of small (or tiny) generally useful changes forward all the time.

推荐答案

Rebase 有利于 集成上游分支进入自己的本地分支，前提是不推送所述本地分支(因为该本地分支的历史已被重写).参见例如 git 工作流程和 rebase 与合并问题".

Rebase is good for integrating upstream branches into one's local branch, provided one does not push said local branch (since the history of that local branch has been rewritten). See for instance "git workflow and rebase vs merge questions".

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

A dedicated "public" branch (i.e. meant to be pushed) should be dedicated in each of the developers Git repository, in order to merge/cherry-pick the relevant changes to push.
Potentially, several public branches could coexist, one per kernel version to maintain/fix, if needed.

然后可以将中央存储库设置为集成(即拉取)推入其中的所有开发人员分支.

A central repo can then be set to integrate (i.e. pulled) all the developer branches pushed in it.

另请参阅git 发布管理"，了解有关合并工作流程和发布的更多信息主题.

See also "git releases management" for more on the merge workflow and publication topics.

这篇关于用于企业 Linux 内核开发的 Git 工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！