Как организовать проекты в Git для двух проектов с общими модулями?

Question

Теперь я столкнулся с проблемой организации кода двух проектов в Git. Есть два программного обеспечения A и B, можно сказать, что B - это то же самое, что и A, только то, что у него есть несколько дополнительных модулей (больше возможностей). Итак, проблема в том, что у меня есть два проекта, но я не могу просто разделить их на два репозитория, поскольку они совместно используют 4/5 одинаковых файлов. A и B скомпилированы, чтобы быть двумя отдельными выпусками программного обеспечения, так как я могу организовать их так, чтобы это имело смысл?

Я думал о том, чтобы иметь 2 репозитория, но как я могу заставить его работать так, чтобы при изменении чего-либо в A, B также обновлялся? Как это работает в Git (извините, я еще не использовал Git на более продвинутом уровне)? И если я смогу скомпилировать B (сделать релиз), не компилируя A одновременно? Буду признателен за любую помощь, и если я не описал что-то должным образом, пожалуйста, дайте мне знать. Заранее большое спасибо.

Answer 1

Краткий ответ:

Скорби, проба и возможное повреждение мозга

Длинный ответ:

Это зависит. В зависимости от вашего языка, фреймворков и т. Д. Вы должны стремиться изолировать «дополнительные модули (дополнительные функции)» в отдельный программный пакет и управлять ими в своем собственном репозитории. Таким образом, вы можете просто изменить конфигурацию (npm package.json, Python Pipfile, ruby ​​gemfile и т. Д.), Чтобы добавить дополнительные функции и включить их с помощью переменных среды. Каждый «проект» получает свои собственные файлы конфигурации, которые будут включать подмножество или расширенный набор функций.

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

Это все еще зависит от конкретных требований, языков программного обеспечения, инструментов и т. Д.

Answer 2

У вас есть несколько вариантов, и они должны использоваться в комбинации.

• Превратить различия между A и B. в параметры конфигурации.
• Извлечь общие биты между A и B.
• Извлечение дополнительных функций в виде модулей.

Конфигурация может означать включение и выключение функций с помощью флагов конфигурации.Это также может означать наличие отдельных шаблонов для A и B. A и B становятся сохраненными конфигурациями.Это, вероятно, лучше всего подходит для изменений, которые в основном носят косметический характер, или если функции достаточно интегрированы в процесс, например, учетные данные базы данных и API.

Остальные биты будет иметь смысл извлекать в модули.Подклассы, позволяющие подключаться, например, к новым базам данных или API.

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

base/
modules/
    feature1/
    feature2/
releases/
    A/
        config
        templates/
    B/
        config
        templates/

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

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

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

Наконец, вы будете управлять каждым репозиторием отдельно как своим собственным проектом.Делайте выпуски так же, как и для любого проекта, использующего обычную систему вашего языка для распространения модулей (Ruby gems, Javascript npm, пакеты Python и т. Д.), Возможно, с использованием частного хранилища модулей.Затем A и B становятся установками, используя систему зависимостей вашего языка, чтобы выбрать, какие дополнительные функции устанавливать.

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