Правильный рабочий процесс Git для комбинированной ОС и частного кода?

У меня есть проект с закрытым исходным кодом, который построен на моей открытой исходной структуре. Я хочу знать, как я должен структурировать свой рабочий процесс. Ниже приведено мое предположение, используя git с подмодулями.

  • Я создаю публичный репозиторий структуры github с подмодулями, которые отдельный репозиторий git.
  • Я покупаю "микро" счет на github (7 долларов США), поэтому я может иметь частное репо.
  • Я создаю частное репо и клонирую репозиторий публичной структуры.

Здесь я могу внести изменения:

  • Мой личный код и нажмите на мое личное репо на github
  • Открытый каркасный код и нажмите на мое частное репетирование github, а затем отправьте запрос на перенос из общедоступной структуры..? Или как это будет работать?

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

Я ищу лучший ответ, который может помочь кому-то довольно новому для git упорядочить процесс работы с кодовой базой, которая является половиной открытого источника и наполовину частной. Одна хорошая вещь в этом заключается в том, что каждая папка является частной или общедоступной, поэтому нет никакого беспокойства о совместном использовании частных и общедоступных файлов - все же некоторые из частных папок могут быть публичными!

Другим примером, который я мог бы дать, будет использование zendframework для создания вашего сайта частной компании, в то же время способного каждый раз тянуть (и, возможно, патч-толкать), на zend-репо. А также тянет и толкает ваш частный сайт внутри zendframework.

Например, представьте структуру каталогов следующим образом:

/private_folder
/public
        /public_folder
        /public_folder2
        /private_folder

Возможно, я попрошу двух способов справиться с ними в одном объединенном каталоге репо. Возможно, нет простого способа сделать это, и я должен разделить их и сделать все публичные патчи в одном, а затем просто втянуться в свое частное репо. Конечно, это означает, что если я нахожусь в середине работы над каким-то частным кодом - мне придется покинуть это репо и открыть открытый файл и внести исправленный код, а затем вернуться к частному, объединить, а затем продолжить работу с частным кодом.

ОТВЕТЫ

Ответ 1

Я рекомендую не использовать подмодули git, но 2 разных репозитория, которые не подключены к github.

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

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

Это можно сделать, сохранив рабочую копию os и частного репозитория git где-то на вашей локальной машине:

/repos/myproject-os
/repos/myproject-priv

Затем вы можете создать структуру своего каталога, в которой проект будет жить и работать где-то еще на этом компьютере (не внутри /repos/tree ), и создавать симбиски для подкаталогов, которые вы используете:

ln -s /repos/myproject-os/dir1 /wrk/myproject/base/dir1
ln -s /repos/myproject-os/dir2 /wrk/myproject/base/dir2
ln -s /repos/myproject-priv/dir1 /wrk/myproject/base/dir3
ln -s /repos/myproject-priv/dir2 /wrk/myproject/base/someother/dir4
mkdir /wrk/myproject/base/config
mkdir /wrk/myproject/base/tmp

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

Вы выполнили бы git коммиты и все из дерева /repos/, и ваш проект запустится, и вы отредактируете файлы из /wrk/tree. Обратите внимание, что директива .git, в которой живут данные git, не будет доступна из /wrk/tree, потому что вы только ссылаетесь на подкаталоги (или, возможно, на отдельные файлы из корневого каталога).

Часть 2: Вы говорите, что хотите убедиться, что вы случайно не ввели закрытый код в общий репозиторий. Вы можете настроить дополнительный репозиторий git между вашим рабочим репозитором ОС и репозиторием github, допустим, вы поместили его в /repos/gatekeeper, тогда ваше дерево выглядит следующим образом:

/repos/gatekeeper/myproject-os
/repos/myproject-os
/repos/myproject-priv

Каждый раз, когда вы нажимаете /repos/myproject -os, он переходит в /repos/gatekeeper/myproject -os. Но из /repos/myproject -priv вы нажимаете прямо на свое частное репетирование github.

Таким образом, у вас есть тот же рабочий процесс как в /repos/myproject -os, так и в repos/myproject-priv, и вам не нужно так беспокоиться. Время от времени, когда вы хотите внести изменения в настоящую кодовую базу ОС, перейдите в /repos/gatekeeper/myproject -os и нажмите оттуда в github.

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

Если вам нужна дополнительная безопасность, /repos/gatekeeper/myproject -os также могут быть на другой машине или даже в другом месте.

Ответ 2

В вашем локальном репозитории вы можете иметь ветвь "public" и 'private'. Когда вы нажимаете, каждая ветвь попадает в отдельный удаленный репозиторий (смотрите синтаксис "git push" ). Затем вы можете свободно сливаться с публичного на личный.

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

Ответ 3

git submodules позволяет вам определить конфигурацию (см. этот вопрос), то есть ссылку на одно коммитирование другого компонента (в другом репо).

Вы можете разрабатывать оба кода (ваш и подмодули) в пределах одного и того же репо, но когда вы говорите о нескольких частных каталогах в своем общедоступном коде, это вызывает стратегия слияния поддерева.
Это позволит вам рассматривать ваши каталоги (частные и общедоступные) как одно естественное рабочее дерево.

И чтобы лучше управлять push и pull частей вашего глобального репо частному, я бы рекомендовал git инструмент поддерева script.

Ответ 4

Подводя итог, рекомендую этот рабочий процесс:

  • держите его простым; иметь одну рабочую копию для каждого репозитория (не использовать подмодули git)
  • используйте свои языковые инструменты для упаковки вашей инфраструктуры.
  • установочные скрипты или световые инструменты для быстрого или автоматического переключения контекста.

Я использовал подмодули git в прошлом. Я не думаю, что они подходят для вашего случая использования. Большие минусы, которые выпрыгивают на меня, следующие:

  • Это помогает съесть свою собачью пищу, когда вы строите (или извлекаете) рамки. Ожидаете ли вы, что ваши пользователи фреймворка также настроят подмодули git, когда они будут использовать вашу фреймворк? Я предполагаю, что нет.
  • Существует некоторый риск случайно опубликовать ваш собственный исходный код в вашей среде с открытым исходным кодом.
  • Git подмодули улучшились совсем немного за последний год или около того, но они все еще относительно менее понятны. Даже компетентные горьки могут бороться с подмодулями.

Вот один из подсубъектов, который, как я признаю, не столь ясен: "Какой рабочий процесс облегчает возврат назад и вперед между инфраструктурой OSS и частным проектом?"

  • Существует определенное желание использовать подмодули и иметь оба проекта в одном дереве. Это ускорит вас, возможно, в вашем текстовом редактировании, но, вероятно, будет замедлять вас (или вызывать больше ошибок, чем обычно), когда дело доходит до совершения и нажатия.

  • Существует определенная привлекательность для разделения проектов. Переключение контекста (из одного окна текстового редактора в другое) может напоминать вам, что проект OSS предназначен для общественного потребления. Например, это может помочь дисциплинировать вас, чтобы не нарушить совместимость и сохранить хороший журнал изменений. Согласование и толкание будет легко относительно альтернативы подмодуля.

Один из них, который вы определили с вашими рабочими копиями, вы захотите выяснить свой рабочий день. Конечно, это будет зависеть от вашего языка. (В Ruby, например, вы можете упаковать свою инфраструктуру OSS в качестве драгоценного камня, создать ее, а затем зависеть от вашего личного кода.) Независимо от того, что вы выбираете, настройте некоторые сценарии (или, возможно, ярлыки для редакторов), чтобы помочь вам создавать свои библиотеки (или пакетов) быстро, возможно, даже автоматически, когда файлы меняются, так что вы можете легко отскакивать между своей инфраструктурой и проектом.

Ответ 5

Здесь два подхода:

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

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

Что мне кажется, вы не можете потерять, если какой-то проект дань каждому проекту, поэтому, если у вас это ясно, то независимо от того, что вы выберете, он будет работать!!!!!!. Кроме того, git легко.

Ответ 6

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