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.
来源：https://stackoverflow.com/questions/1856241/git-workflow-for-corporate-linux-kernel-development