Git частные и публичные репозитории для одного и того же проекта

Вопрос от новичка Git: у меня есть проект в репозитории Git, части которого я хотел бы сделать доступным как OSS. По практическим соображениям, хранилища частной и публичной частей проекта должны быть разными, в то время как все разработки будут происходить в частном репозитории. В определенные моменты времени я хотел бы обновить версию OSS с выбранными коммитами из частной версии.

Прямо сейчас у меня есть удаленная ветвь частной настройки репо в локальном зеркале публичного репо, и я использую git cherry-pick для копирования интересных коммитов из удаленной ветки частного репо для управления ветвью публичной репо, которое я тогда нажимаю. Однако, поскольку частное развитие движется очень быстро, сбор вишни может занять много времени.

Есть ли предложения о том, как сделать рабочий процесс немного лучше?

Кстати, я прочитал SO questions # 999064 и # 1807036

Ответ 1

Один из возможных вариантов - использовать git rebase -i, чтобы предоставить вам текстовый файл всех коммитов в определенном диапазоне в вашем личном. Скажите, что вы private и public головами и имеете 10 новых коммитов в ветке 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

Если вы поддерживаете ветвь lastsync, подобную этой, в дополнение к вышесказанному, вы можете заменить private ^ 10 на lastsync и не отслеживать количество оборотов:

git checkout lastsync
git merge private

Ответ 2

В то время как то, что я собираюсь предложить, вероятно, похоже на ответ от # 999064, я отдам его.

В основном вы хотите использовать две ветки. master - ваш основной филиал, в который входит вся ваша общественная работа. work - ваш частный филиал. Так что вы делаете, когда вы хотите, чтобы изменения были доступны для публики, вы делаете это commit на master. Если фиксация является частной, вы делаете ее на ветке work.

Трюк состоит в том, чтобы объединить master обратно в work непрерывно. Таким образом, work будет иметь все изменения master, но master будет содержать только те коммиты, которые были сделаны на master.

Итак, что вы получаете:

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

master содержит коммиты a, b, d, f, g. work содержит сумму слияния c (содержит a, b), h (содержит d, f, g) и регулярное совершение e.

e находится только в ветки work, а все остальные коммиты (кроме коммитов) - на обеих ветвях.

Пример того, как создать приведенный выше график:

# 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

Итак, у вас есть два пульта, public и private. Вы нажимаете work и master на private, но вы только нажимаете master на public.

Я надеюсь, что это поможет.

Ответ 3

Я могу думать об одном способе. Вы можете сделать публичные репозитории подмодули основного проекта, а затем развить их отдельно, но в то же время использовать их из основного проекта.

Тем не менее, я думаю, что вы действительно должны создавать отдельные репозитории для основного и общедоступного компонентов и устанавливать последние зависимости для первых, которые установлены отдельно.