Menu
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:
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.
494
The kernel development is a continuous process. A new version of the kernel is released when a set of features and bug fixes are ready. These new versions are called kernel releases. This process initiates with Linus Torvalds, wherein, he releases a new kernel and then opens a 2-week merge window.
The normal workflow is to develop and check in on a branch, then once everything is happy, merge the branch back into the master. The local repository consists of three "trees" maintained by git. The first one is your Working Directory which holds the actual files.
The Gitflow Workflow defines a strict branching model designed around the project release. This workflow doesn't add any new concepts or commands beyond what's required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact.
Git Team Workflow: Branchesmaster branch. staging branch.
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.
161
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
