¿Cuál es el mejor flujo de trabajo de Git para trabajar con un proyecto de código abierto con cambios específicos del empleador?

En mi empleador actual, estamos utilizando un proyecto de código abierto alojado en Github como componente de nuestra aplicación. He estado trabajando en este proyecto para agregar algunas características que necesitamos e integrarlo con nuestros sistemas de compilación. Mi gerente y yo estamos de acuerdo en que nos gustaría presentar tanto de nuestro trabajo en este componente como sea razonable de regreso al proyecto de código abierto. Mi pregunta es sobre cuál es el mejor flujo de trabajo / técnica para mantener mis confirmaciones de Git de tal manera que pueda separar fácilmente las cosas que tienen sentido para agregar al proyecto de código abierto: correcciones de errores y nuevas características que son lo suficientemente generales. de cosas que son específicas de nuestro proyecto, como ubicaciones de construcción y constantes de aplicación.

Lo que he estado haciendo hasta ahora es mantener una rama privada de Git donde confirmo todos mis cambios, con la granularidad adecuada. Luego uso cherry-pickpara agregar las confirmaciones de código abierto a la rama maestra y enviarlas de nuevo a Github.

Parece que debería estar usando merge para hacer esto, de modo que no sigo creando commits separados con contenidos idénticos, pero no estoy seguro de cómo hacerlo mientras excluyo los commits específicos de la compañía y mantengo un flujo de trabajo razonable.

Por ejemplo, supongo que podría comprometer cosas de código abierto en el maestro y cosas específicas de la compañía en la rama privada, y luego fusionar el maestro en esa rama según sea necesario, dejando que la rama maestra apunte al compromiso antes de la fusión, de modo que pueda cometer cosas de código abierto nuevamente y luego fusionar nuevamente. Lo que parece extraño acerca de este flujo de trabajo es que tendría que decidir de antemano todo lo que hago a qué rama pertenecía, trabajar en lo que parecía completar, luego comprometerlo y fusionarme antes de probar. Una de las cosas que realmente me gusta de Git es lo fácil que es hacer lo que sea necesario para que su aplicación funcione, y luego decidir cómo y dónde confirmar sus cambios. Por lo que puedo decir, si actualmente estás en una sucursal y tienes algo de trabajo, allí '

¿Lo que estoy haciendo es un flujo de trabajo razonable para las contribuciones a largo plazo? ¿Alguien puede recomendar un flujo de trabajo diferente que podría ser mejor y por qué es mejor?

Aquí hay una estrategia que podría funcionar para usted:

Cree 2 repositorios privados de git, con un repositorio para el trabajo de la empresa y el otro para el repositorio general (me gustaría confirmar).

Para que este sistema funcione, debe hacer esto (lo cual considero la estrategia más importante): definir qué es "general" y puede ser utilizado por todos los demás en la comunidad

Al tener esta definición, puede separar lo que volverá a comprometer y lo que no necesita comprometer.

Tiene sentido que lo que codifique para la comunidad sea de forma general, ya que un código demasiado específico no beneficiará a nadie (y puede que ni siquiera llegue a la rama maestra).

Ahora que sabe lo que va a comprometer con la comunidad, puede hacer la mayoría del trabajo de "devolución" en el repositorio dedicado a él. Luego, simplemente transfiere ese repositorio a su repositorio basado en el trabajo y realiza cualquier trabajo específico por encima de eso.

Sospecho que pasará mucho más tiempo en el repositorio de "devolución", así que recuerde proporcionar comentarios valiosos, etc. (tal vez incluso documentación) para las personas que usarían ese proyecto en el futuro.

También creo que git puede hacer mucho más de lo que piensas. Vi este video en Vimeo: http://vimeo.com/46010208 e hizo un trabajo brillante al explicar muchas cosas extrañas que Git puede hacer.

Mi estrategia no es la única, pero definitivamente puede ser un punto de partida para que pienses en 1 que se adapte específicamente a ti.

Dependiendo de la naturaleza de la base de código de código abierto y de lo que necesita lograr al hacer cambios, puede obtener mucho kilometraje separando sus preocupaciones. En la bifurcación del proyecto, solo agregue las cosas que tiene la intención de contribuir al original. Agregue ganchos o puntos de extensión para permitirle hacer el trabajo de su empresa que no se compartirá.

De esta manera, nunca tendrá que preocuparse por dividir o decidir de antemano qué compartir y qué no compartir. Debido a que agregó flexibilidad al proyecto original, siempre podría optar por compartir algunas partes del trabajo de su empresa más adelante.