Flujo de trabajo de Git para el desarrollo corporativo del kernel de Linux

Question

Trabajo para una compañía que construye sistemas embebidos usando Linux. Históricamente siempre usamos CVS para almacenar nuestro trabajo de kernel. Nuestros granos terminan siendo una colección de:

• Controladores para nuestro hardware propietario
• correcciones de azar para los bits de Linux que usamos
• controladores de hardware no-propietarios
• hacks yukky azar para adaptar Linux para nuestra aplicación

estamos en la etapa en la que nos gustaría reajustar algunos de nuestros núcleos más antiguos en las versiones más recientes, así como la fijación de nuestro flujo de trabajo de CVS arcaica a algo basado en conjuntos de cambios. La elección obvia es git.

Estoy luchando por encontrar un flujo de trabajo sensato. He exportado nuestro repositorio de CVS para uno de nuestros núcleos y tengo una colección de conjuntos de cambios sobre el núcleo de Linus base apropiado. ¿A donde voy desde aqui?

Me gustaría tener un repositorio central en el que todos los desarrolladores realicen cambios. ¿Es seguro usar rebase para mover nuestra colección de conjuntos de cambios a una nueva revisión de kernel base y luego hacer que nuestros desarrollos se lleven a cabo en la parte superior de la nueva rama central?

Puntos de bonificación para obtener un flujo de trabajo que nos permite separar fácilmente los cambios que pueden ser adecuados para la subida. Estoy harto de empujar una colección de pequeños (o pequeños) cambios generalmente útiles todo el tiempo.

Answer 1

Rebase es bueno para integrating upstream branches en una rama local, siempre que no se presione dicha rama local (ya que el historial de esa rama local se ha reescrito). Ver por ejemplo "git workflow and rebase vs merge questions".

Se debe dedicar una rama dedicada "pública" (es decir, destinada a ser empujada) en cada uno de los desarrolladores del repositorio de Git, con el fin de merge/cherry-pick los cambios relevantes para empujar.
Potencialmente, varias ramas públicas podrían coexistir, una por versión del kernel para mantener/corregir, si es necesario.

Un repositorio central se puede configurar para integrar (es decir, extraer) todas las ramas de desarrollador que se insertan en él.

Consulte también "git releases management" para obtener más información sobre el flujo de trabajo de fusión y los temas de publicación.