Git rebase se subdivide en otra subranición

Esto puede o no haber sido respondido ya, pero como no sé cuál es la terminología exacta para lo que quiero hacer, será difícil encontrarlo mediante la búsqueda.

Aquí está mi layout de proyecto git actual:

master | |-branch-a |-branch-b |-branch-c 

Me he dado count de que hay casos en los que los cambios que realizo en las tres subramificaciones son lo suficientemente similares como para aplicarlos sobre el master . Sin embargo, el master es mi "twig de import", donde importo código actualizado de fonts externas antes de fusionarlo en las subártwigs.

Así que creo que la mejor manera de hacerlo es crear una sub-twig fuera de master , decir fixes , y luego tener mis sub-twigs:

 master | |-fixes | |-branch-a |-branch-b |-branch-c 

Una vez que haga eso, tendré que de alguna manera desentrañar las twigs existentes con cualquier código fijo en la twig de fixes . Pero creo que la parte más difícil es volver a basar mis subtwigs en la twig de fixes sin estropear mi repository.

Cabe destacar que cada una de las subtwigmas contiene código que necesita permanecer independiente de los demás. Básicamente el desarrollo en paralelo en diferentes ideas. Uno o más podrían fusionarse más adelante en el path de return al master . Asumiendo que, si no tengo correcciones que se apliquen a todas las subramificaciones, entonces las fixes son básicamente solo un espejo del master .

¿Cómo puedo hacer esto?

Editar: porque no puedo dibujar ASCII en los comentarios, esto es en respuesta a la respuesta del usuario3236304 .

Creo que veo a lo que te refieres. En su lugar, ¿debería orientar mis twigs de esta manera ?:

 master (core fixes go here) | |-upstream | |-branch-a |-branch-b |-branch-c 

De esa forma, puedo aplicar mis propios arreglos básicos locales en el master y usar la twig upstream para rastrear los cambios desde el origen, uniéndolos a mis twigs locales cuando sea necesario.

Haría esto un poco diferente; master es su twig común de trabajo de integración: {a, b, c} son twigs de publicación específicas, y usted mantiene una twig específica 'upstream', que importa de dicha cadena ascendente.

La ventaja es que tienes un área específica para doblar continuamente los cambios, construyendo hacia nuevos lanzamientos, con la expectativa de que cada twig sea {derivada, b, c} probable derivativa (más cercana) a ese punto de ramificación común .

En cuanto a la gestión de la twig común, a partir de los sonidos de la misma se realizan fusiones / selects de cerezas ocasionales; esto funciona bien, y una estructuración de este tipo hace que sea fácil hacer una base de reference de lo común para eliminar el ruido / CL muertos, minimizando el delta histórico del flujo ascendente real.

Independientemente del enfoque, le sugiero que retroceda un paso e intente decidir si considera que su trabajo es el verdadero "maestro" para los demás (lo sacarán de usted), o si usted es un derivado de alguna otra fuente. Lo que describí funciona razonablemente bien si eres un derivado; si eres el "maestro", entonces probablemente quieras algo diferente.