¿Flujo de trabajo de Git para mantener un fork de extensión de proyecto?

Question

Hemos bifurcado un proyecto de OSS en GitHub y le agregamos algunas extensiones personalizadas. Queremos enviar algunos de los cambios que realizamos al proyecto original (correcciones de errores y similares) pero otros cambios son extensiones de funciones que los mantenedores originales del proyecto no están interesados ​​en este momento. Estoy tratando de encontrar el mejor flujo de trabajo para manejar esta situación.

Quiero que nuestra rama principal contenga la suma de (confirmaciones del proyecto original) + (nuestras correcciones de errores para la contribución) + (nuestras extensiones personalizadas). Me imagino que querremos un modelo de rama por función para que podamos mantener las correcciones de errores separadas de las extensiones personalizadas. Podemos comenzar ramas de extensión personalizadas desde nuestra rama principal, pero supongo que también querremos mantener una rama de "origen" local o algo que rastree el proyecto original para que podamos comenzar desde ahí las ramas de corrección de errores que no estén contaminadas con nuestro cosas personalizadas O algo.

¿Alguien puede sugerir la mejor manera de estructurar este flujo de trabajo para que todos los diferentes compromisos lleguen a donde se supone que deben ir y ninguno vaya donde no se supone que deben ir?

Answer 1

Me parece que ya ha respondido su propia pregunta. Cree una rama llamada "vainilla" o algo que rastree la rama principal de la corriente ascendente, y tenga una rama "maestra" que contenga sus extensiones personalizadas. Crea ramas para cada cosa que haces. Para las correcciones de errores, empiece con "vainilla". Para sus propias cosas, comience con el maestro. De vez en cuando, une vainilla en maestro. Para obtener las correcciones de errores en su rama de extensiones personalizadas, podría fusionar sus ramas en el maestro directamente, o simplemente esperar a que las respuestas acepten sus solicitudes de instalación de corrección de fallas, y luego la siguiente combinación de vanilla a maestro contendría las correcciones de errores. Esto parece un flujo de trabajo muy normal.

Answer 2

Lo que quiere configurar es un largo plazo fork, para hacer esto ya que descubrió que la solución podría ser la creación de una rama especial vinculada con el proyecto original "vanilla" y tener una rama principal donde se mantiene su copia de trabajo personalizada.

Lo único que hay que tener en cuenta (desde mi punto de vista) es que no se debe fusionar los dos rama cuando se desea sincronizar los cambios, pero en este caso (cuando las ramas divergen) existe es el práctico comando Cherry-Pick de Git que le permite tomar una confirmación simple de una rama y aplicarla a otra, esto podría ser particularmente útil en el caso de mantener una bifurcación porque puede intercambiar fácilmente la confirmación simple de una rama a otra.