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

Question

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

Ahora, tengo una rama remota de la configuración de repositorio privado en un espejo local del repositorio público y estoy usando git cherry-pick para copiar las confirmaciones interesantes de la rama remota del repositorio privado a la rama principal del repositorio público , que luego presiono Sin embargo, dado que el desarrollo privado se está moviendo muy rápido, el "cherry picking" puede consumir mucho tiempo.

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

Por cierto, he leído lo que las preguntas #999064 y #1807036

Answer 1

Una opción posible es usar git rebase -i para darle un archivo de texto de todas las confirmaciones en un cierto rango en su privado. Digamos que usted private y public cabezas y con 10 nuevas confirmaciones en private rama:

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 rama lastsync como esto en adición a lo anterior, se puede reemplazar privada^10 con lastsync y no tener que realizar un seguimiento de rev cuenta:

git checkout lastsync 
git merge private 

Answer 2

No puedo pensar en una manera. Puede hacer los repositorios públicos submodules del proyecto principal y luego desarrollarlos por separado pero al mismo tiempo usarlos del proyecto principal.

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

Answer 3

Si bien lo que estoy a punto de sugerir es probablemente similar a la respuesta del #999064, lo intentaré.

Básicamente lo que quiere es usar dos ramas. master es su rama principal a la que pertenece todo su trabajo público. work es su sucursal privada. Entonces, lo que usted hace es siempre que desee que un cambio esté disponible para el público también, usted lo confirma en master. Si la confirmación es privada, la haces en la rama work.

El truco es fusionar master de nuevo en work continuamente. De esta manera, work tendrá todos los cambios de master, pero master solo contendrá las confirmaciones que se hicieron específicamente en el master.

Así que lo que se obtiene es:

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

master contiene los compromete 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 rama work, mientras que todas las demás confirmaciones (excepto las de fusión) están en ambas ramas.

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 

lo que tiene dos mandos a distancia, public y private. Empuja work y master a private, pero solo empuja master a public.

Espero que ayude.