Flujo de trabajo para la horquilla Git en caso de una dirección de desarrollo diferente

La situación es que tenemos un producto que creamos para masas, lo tenemos en un repository de GIT (vamos a llamarlo en upstream ). Uno de nuestros clientes quería una versión personalizada del producto, así que la bifurcamos y la mantuvimos en un repository diff GIT (vamos a llamarlo origin ).

Idea es liderar el repository de origen en su propia dirección de desarrollo para la personalización del cliente y, a la vez, continuar recibiendo actualizaciones desde el inicio.

He agregado el upstream como un control remoto a mi repository local donde lo estoy desarrollando, y soy consciente de que puedo extraer las actualizaciones desde el inicio, fusionarlas o lo que parezca bien, pero me gustaría saber de alguien que ha hecho esto o lo ha hecho ¿para hacer que el flujo de trabajo sea más suave y evitar posibles escollos?

Editar: ¿Haría fusión-combinar el event handlingl flujo de trabajo como los mismos cambios en ambos repositorys? Al igual que el trabajo ya comenzó en fork y algunas cosas lo arreglé en origen, pero también necesitaría la misma solución en el upstream. Entonces, ¿debería hacer otra confirmación en la etapa inicial para corregir eso y git puede detectar la similitud al fusionarlos la próxima vez para actualizar el fork o debería haber comprometido esa corrección como una confirmación separada incluso si califica para la confirmación de trabajo que hice? Mi preocupación se parece más a cómo puedo hacer que este process funcione con la mínima fricción.

Otra pregunta: Usar cherry-pick parece una buena idea para pequeños cambios. ¿Pensamientos?

Si es posible, evite hacer una selección de cerebros debido a un problema de fusión futuro (como se menciona en " Cómo fusionar una confirmación específica en git ")

La elección de un compromiso de una twig a otra consiste básicamente en generar un parche y luego aplicarlo, perdiendo así también la historia.

Este cambio de identificadores de commit rompe la funcionalidad de fusión de git entre otras cosas

Intente aislar los cambios que sabe que necesitará aplicar al otro repository en sus propios commits, para aplicar solo esos cambios.
Luego, una git fetch , seguida de una rebase de su sucursal, es la mejor manera de include en su historial de sucursal los commits desde el nivel superior.
Esto es similar al flujo de trabajo descrito en " git workflow y rebase vs merge questions " (consulte la sección de actualización).

Para evitar la elección selectiva, es posible que necesite echar un vistazo al layout / architecture del sistema. Cuanto más se divida en modules funcionales, utilizando mecanismos de inserción, etc., más fácil será agregar funciones y actualizaciones a ambas twigs.

Si el sistema no está perfectamente dividido en modules, ningún flujo de trabajo de git resolverá sus problemas durante las fusiones y las fusiones se volverán cada vez más complejas.