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

Question

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

1. Я создаю публичный репозиторий на GitHub с подмодулями, которые отдельные репозитории git.
2. Я покупаю "микро" аккаунт на github (7 $), поэтому я может иметь личное репо.
3. Я создаю частное репо и клонирую общедоступный репозиторий.

Отсюда я могу внести изменения в:

1. Мой личный код и отправка в мой личный репозиторий на github
2. Код общедоступной платформы и отправка в мое частное репозиторий github, а затем отправка запроса извлечения из общедоступной платформы.? Или как это будет работать?

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

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

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

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

/private_folder
/public
        /public_folder
        /public_folder2
        /private_folder

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

Answer 1

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

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

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

Это можно сделать, сохранив рабочую копию операционной системы и частного репозитория 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 / tree, и ваш проект запустится, и вы отредактируетефайлы из дерева / wrk /.Обратите внимание, что директория .git, в которой находятся данные git, не будет доступна из / wrk / tree, поскольку вы ссылаетесь только на подкаталоги (или, возможно, отдельные файлы из корневого каталога).

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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