Repositorios privados y públicos de Git para el mismo proyecto

Pregunta de un novato de Git: Tengo un proyecto en un repository de Git, partes del cual me gustaría poner a disposition como OSS. Por razones prácticas, los repositorys de las partes privada y pública del proyecto deberán ser diferentes, mientras que todo el desarrollo ocurrirá en el repository privado. En ciertos momentos, me gustaría actualizar la versión de OSS con confirmaciones seleccionadas de la versión privada.

En este momento, tengo una twig remota de la configuration de repository privado en un espejo local del repository público y estoy usando git cherry-pick para copyr las confirmaciones interesantes de la twig remota del repository privado a la twig principal del repository público, que luego presiono Sin embargo, dado que el desarrollo privado se está moviendo muy rápido, el "cherry picking" puede consumir mucho time.

¿Hay alguna sugerencia sobre cómo hacer que el flujo de trabajo sea un poco mejor?

Por cierto, leí SO SO preguntas # 999064 y # 1807036

Una opción posible es usar git rebase -i para darle un file de text de todas las confirmaciones en un cierto range en su privado. Digamos que son jefes private y public , y tienen 10 nuevos compromisos en private sucursal private :

 git checkout private git pull git checkout -b work git rebase -i --onto public private^10 # an editor pops up listing the commits. Just delete the private ones. git checkout public git merge work git branch -d work git push 

Si mantiene una bifurcación de synchronization similar a esta además de la anterior, puede replace private ^ 10 con lastsync y no tener que rastrear recuentos de revoluciones:

 git checkout lastsync git merge private 

Si bien lo que voy a sugerir probablemente sea similar a la respuesta del número 999064 , lo intentaré .

Básicamente lo que quieres es usar dos twigs. master es tu twig principal a la que pertenece todo tu trabajo público. work es tu twig privada. Entonces, lo que haces es cuando quieras que un cambio esté disponible para el público también, haces que se comprometa con el master . Si el compromiso es privado, lo haces en la twig de work .

El truco es fusionar el master nuevo en el work continua. De esta forma, el work tendrá todos los cambios de master , pero el master solo contendrá los commits que se realizaron específicamente en el master .

Entonces lo que obtienes es:

 -- work --------- c -- e ------- h / / -- master -- a -- b -- d -- f -- g 

master contiene los commits a, b, d, f, g. work contiene los commit de fusión c (contiene a, b), h (contiene d, f, g) y el commit regular e.

e está solo en la twig de work , mientras que todas las demás confirmaciones (excepto las asignaciones de fusión) están en ambas twigs.

Un ejemplo de cómo producir el gráfico anterior:

 # on branch master # changes for a git add . git commit -m 'commit a' # changes for b git add . git commit -m 'commit b' # switch to work # merge a and b (from master) into work, producing merge commit c git checkout work git merge master # switch to master # make commits d, f and g git checkout master ... # switch to work # make commit e # merge d, f and g (from master) into work, producing merge commit h git checkout work git merge master 

Entonces tienes dos controles remotos, public y private . Empuja el work y el master a private , pero solo envía el master al public .

Espero que eso ayude.

Puedo pensar de una manera. Puede crear los repositorys públicos como submodules del proyecto principal y luego desarrollarlos por separado, pero al mismo time usarlos desde el proyecto principal.

Sin embargo, creo que realmente debería hacer repositorys separados para los componentes principal y público y hacer las últimas dependencies para el primero que se instalan por separado.