Git prywatne i publiczne repo dla tego samego projektu

Question

Pytanie od początkującego Gita: Mam projekt w repozytorium Git, którego części chciałbym udostępnić jako OSS. Ze względów praktycznych, repozytoria prywatnych i publicznych części projektu będą musiały być inne, a cały rozwój będzie się odbywał w prywatnym repozytorium. W pewnych momentach chciałbym zaktualizować wersję OSS o wybrane zatwierdzenia z wersji prywatnej.

W tej chwili mam zdalny oddział prywatnego repoinstalacji w lokalnym zwierciadle publicznego repozytorium i używam git cherry-pick do kopiowania interesujących zatwierdzeń ze zdalnego oddziału prywatnego repo do głównego repozytorium publicznego repo , które następnie pcham. Jednakże, ponieważ rozwój prywatny porusza się bardzo szybko, zbieranie wiśni może być bardzo czasochłonne.

Czy są jakieś sugestie, jak usprawnić przepływ pracy?

BTW, czytałem SO pytania #999064 i #1807036

Answer 1

Jedną z możliwych opcji jest użycie git rebase -i, aby udostępnić plik tekstowy wszystkich zatwierdzeń w pewnym zakresie w prywatnym. Say private i public głowy i mieć 10 nowych rewizje w private Branża:

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 

Jeśli utrzymać lastsync oddział takiego w uzupełnieniu do powyższego, można zastąpić prywatny^10 z lastsync i nie trzeba śledzić rev liczy:

git checkout lastsync 
git merge private 

Answer 2

mogę myśleć jeden sposób. Możesz stworzyć publiczne repozytorium submodules głównego projektu, a następnie rozwijać je oddzielnie, ale jednocześnie używać ich z głównego projektu.

Jednak uważam, że powinieneś naprawdę utworzyć osobne repozytoria dla głównych i publicznych komponentów i uczynić te ostatnie zależności dla tych pierwszych, które są oddzielnie zainstalowane.

Answer 3

Podczas gdy to, co zamierzam zasugerować, jest prawdopodobnie podobne do odpowiedzi z #999064, dam mu szansę.

Zasadniczo potrzebujesz dwóch gałęzi. master to Twój główny oddział, do którego trafiają wszystkie twoje prace publiczne. work to Twój prywatny oddział. Więc jeśli chcesz, aby zmiana była również dostępna dla publiczności, musisz ją zatwierdzić na master. Jeśli zatwierdzenie jest prywatne, robisz to w gałęzi work.

Sztuką jest ciągłe scalanie master z powrotem w work. W ten sposób work będzie zawierał wszystkie zmiany master, ale master będzie zawierał tylko te zatwierdzenia, które zostały wykonane specjalnie na master.

Więc co masz jest:

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

master zawiera popełnia, B, D, F, G. work zawiera scalenie zatwierdza c (zawiera a, b), h (zawiera d, f, g) i zwykłe zatwierdzenie e.

e jest tylko w gałęzi work, podczas gdy wszystkie inne zatwierdzenia (z wyjątkiem zatwierdzeń scalania) znajdują się w obu gałęziach.

Przykładem jak produkować powyższy wykres:

# 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 

więc masz dwa piloty, public i private. Przekierowujesz work i master do private, ale naciskasz tylko master na public.

Mam nadzieję, że to pomaga.