Git-Workflow für die Linux-Kernel-Entwicklung in Unternehmen
Ich arbeite für ein Unternehmen, das Embedded-Systeme unter Linux baut. In der Vergangenheit haben wir immer CVS verwendet, um unsere Kernel-Arbeit zu speichern. Unsere Kerne sind eine Sammlung von:
Treiber für unsere proprietäre HardwareZufällige Korrekturen für Linux-Teile, die wir verwendenNicht proprietäre HardwaretreiberZufällige Yukky-Hacks, um Linux für unsere Anwendung anzupassenWir befinden uns in der Phase, in der wir einige unserer älteren Kernel auf neuere Versionen zurücksetzen und unseren archaischen CVS-Workflow auf Basis von Änderungssätzen korrigieren möchten. Die offensichtliche Wahl ist git.
Ich habe Mühe, einen vernünftigen Workflow zu finden. Ich habe unser CVS-Repository für einen unserer Kernel exportiert und habe eine Sammlung von Changesets auf dem entsprechenden Linus-Basiskernel. Wohin gehe ich von hier aus?
Ich hätte gerne ein zentrales Repository, an dem alle Entwickler Änderungen vornehmen. Ist es sicher, rebase zu verwenden, um unsere Sammlung von Änderungssätzen auf eine neue Basis-Kernel-Revision zu verschieben, und müssen unsere Entwicklungen dann auf dem neuen zentralen Zweig ausgeführt werden?
Bonuspunkte für den Erhalt eines Workflows, mit dem wir Änderungen, die für den Upstream geeignet sein könnten, auf einfache Weise herausfiltern können. Ich habe es satt, ständig eine Sammlung kleiner (oder winziger) allgemein nützlicher Änderungen voranzutreiben.