Flusso di lavoro Git per lo sviluppo del kernel Linux aziendale

Question

Lavoro per un'azienda che costruisce sistemi embedded utilizzando Linux. Storicamente abbiamo sempre usato CVS per archiviare il nostro lavoro sul kernel. I nostri kernel finiscono per essere una raccolta di:

• driver per il nostro hardware proprietario
• correzioni casuali per i bit di Linux che usiamo
• driver hardware non-proprietarie
• casuali hack yukky di adattare Linux per la nostra applicazione

Siamo al punto in cui vorremmo rebase alcuni dei nostri vecchi kernel sulle versioni più recenti e sistemare il nostro flusso di lavoro CVS arcaico a qualcosa basato su changeset. La scelta ovvia è git.

Sto lottando per ottenere un flusso di lavoro ragionevole. Ho esportato il nostro repository CVS per uno dei nostri kernel e ho una collezione di changeset in cima al kernel base di Linus appropriato. Dove vado da qui?

Mi piacerebbe avere un repository centrale su cui tutti gli sviluppatori eseguono il commit delle modifiche. È sicuro usare rebase per spostare la nostra collezione di changeset in una nuova revisione del kernel di base e poi fare in modo che i nostri sviluppi vengano portati in cima al nuovo ramo centrale?

Punti bonus per ottenere un flusso di lavoro che ci consenta di separare facilmente le modifiche che potrebbero essere idonee a monte. Sono stufo di spingere una serie di piccole (o minuscole) modifiche generalmente utili in avanti in ogni momento.

Answer 1

Rebase è valido per integrating upstream branches nel proprio ramo locale, a condizione che uno non spinga detto ramo locale (poiché la cronologia di quel ramo locale è stata riscritta). Si veda ad esempio "git workflow and rebase vs merge questions".

Una filiale "pubblica" dedicata (vale a dire che deve essere spinto) deve essere dedicata in ciascun repository Git degli sviluppatori, al fine di merge/cherry-pick le modifiche rilevanti per push.
Potenzialmente, diverse filiali pubbliche potrebbero coesistere, una per versione del kernel da mantenere/correggere, se necessario.

Un repository centrale può quindi essere impostato per integrare (cioè trascinato) tutti i rami dello sviluppatore inseriti in esso.

Vedere anche "git releases management" per ulteriori informazioni sul flusso di lavoro di fusione e sugli argomenti di pubblicazione.