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

问题描述

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

• 我们专有硬件的驱动程序


• 随机修复我们使用的Linux版本
  
• 非专有硬件驱动程序


• 随机yukky为我们的应用程序量身定做Linux
  

我们正处于我们想要在新版本上重新构建一些旧内核的阶段，以及将我们陈旧的CVS工作流修复为基于变更集的东西。明显的选择是git。

我努力想出一个合理的工作流程。我为我们的内核之一导出了我们的CVS存储库，并在适当的基本Linus内核之上收集了一些变更集。我该从哪里出发？

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

获得工作流程的额外要点，使我们能够轻松分离出可能适合上游的更改。我厌倦了一直推动一些小的（或微小的）通常有用的变化。

Rebase很好对于将上游分支机构集成到一个本地分支机构中，只要不推动所述本地分支机构（因为该地方分部的历史已被重写）。请参阅git workflow and rebase vs merge questions。

专用的公共分支（即意味着推送的）应该在每个开发人员Git仓库中专用，以便 merge /cherry-pick 推动相关变化。

可能有几个公共分支可能共存，每个内核版本一个维护/修复，如果需要的话。

然后可以设置一个中央仓库来集成（即拖拽）所有的开发者分支。 / p>

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

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:

• Drivers for our proprietary hardware
• Random fixes for bits of Linux we use
• Non-proprietary hardware drivers
• Random yukky hacks to tailor Linux for our application

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.

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?

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 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".

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.

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

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