我在一家使用 Linux 构建嵌入式系统的公司工作。历史上我们一直使用 CVS 来存储我们的内核工作。我们的内核最终会成为以下内容的集合：
- 我们专有硬件的驱动程序
- 对我们使用的 Linux 部分的随机修复
- 非专有硬件驱动程序
- 为我们的应用程序定制 Linux 的随机黑客攻击
我们正处于一个阶段，我们希望重新构建一些我们将旧内核移植到新版本上，并将我们过时的 CVS 工作流程修复为基于变更集的内容。显而易见的选择是 git。
我正在努力想出一个合理的工作流程。我已经为我们的一个内核导出了 CVS 存储库，并在适当的基本 Linus 内核之上拥有一组变更集。我该去哪里？
我想要一个所有开发人员都可以提交更改的中央存储库。使用 rebase 将我们的变更集集合移至新的基础内核修订版，然后在新的中央分支之上进行开发是否安全？
获得一个工作流程的奖励点使我们能够轻松地分离出可能适合上游的更改。我厌倦了一直推动一系列小的（或微小的）通常有用的改变。
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.
发布评论
评论（1）
Rebase 非常适合将上游分支集成到本地分支，前提是不推送上述内容本地分支（因为该本地分支的历史已被重写）。例如，请参阅“git 工作流程以及 rebase 与合并问题”。
每个开发人员的 Git 存储库都应该有一个专用的“公共”分支（即要推送的分支），以便 合并/cherry-pick要推送的相关更改。
如果需要，多个公共分支可以共存，每个内核版本一个可以维护/修复。
然后可以设置中央存储库来集成（即拉取）推入其中的所有开发人员分支。
另请参阅“git 版本管理”，了解有关合并工作流程和发布主题的更多信息。
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.