Как сохранить `lite` и` pro` библиотеки в git?

Question

У меня есть две версии lite и pro для моей библиотеки. Файлы могут перекрываться, различаться и pro только.

Я бы хотел сохранить их на git, может быть, один на gitlab, а другой на github или оба на gitlab, так как gitlab поддерживает частные репозитории (для моего pro).

Есть ли удобные практики для этого сценария? Я совершенно не люблю совершать действия дважды.

Answer 1

Вы можете использовать один репо.1) Создайте две разные ветки в git, lite и pro.2) Также создайте еще одну ветку с названием dev-lite и dev-pro.Это будет иметь рабочие версии разработчиков.3) Также скажите всем разработчикам, чтобы они ответили на репо.(или создайте отдельную ветвь для каждого разработчика, если разветвление звучит сложно)

Теперь разработчики разветвят ваш репозиторий и отправят изменения в dev-lite и dev-pro, в зависимости от того, над какой веткой они работают.Должен быть администратор, который объединит эти изменения после некоторой проверки кода.

4) Сконфигурируйте сервер сборки Jenkins таким образом, чтобы как только ветка dev-lite или dev-pro обновлялась с помощью коммита, сборка запускалась и публиковалась в соответствующих средах.

5) Теперь наступает этап выпуска, и как только решение принято, вам нужно пометить версию в ветке dev-lite и dev-pro и перебазировать / объединить ваш код с ветками pro и lite,

6) Код этой ветви будет вашим рабочим кодом и будет запущен для клиента в режиме реального времени.

Таким образом, вы можете поместить Lite и Pro в Git в одном репо.

Answer 2

В C # вы можете использовать #if для добавления блоков кода в зависимости от идентификаторов препроцессора, определенных в конфигурации проекта .

Т.е.. вместо просто сборок "Debug" и "Release" у вас есть "Lite-Debug", "Lite-Release", "Pro-Debug" и "Pro-Release" (а в более крупных проектах четыре могут показаться небольшим количеством конфигураций )

Частичные функции также могут помочь (позволяя коду вызывать код, который может присутствовать или не присутствовать).

---

Если вы хотите, чтобы облегченная версия была с открытым исходным кодом, а полная - закрыта, вам нужен другой подход. Либо вы поддерживаете две версии параллельно (что упростит внесение в облегченную версию, но позаботьтесь о последствиях лицензии для копирования изменений сторонних производителей в вашу закрытую версию).

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