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
Я могу думать об одном способе. Вы можете сделать публичные репозитории подмодули основного проекта, а затем развить их отдельно, но в то же время использовать их из основного проекта.
Тем не менее, я думаю, что вы действительно должны создавать отдельные репозитории для основного и общедоступного компонентов и устанавливать последние зависимости для первых, которые установлены отдельно.