Git - функции совместного использования проектов

Question

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

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

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

Я использовал только git последние 2 года, и я не уверен, что освоил его.

Как я могу сделать 2 проекта развиваться и делиться некоторыми функциями с git?

Answer 1

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

• Различные Филиалы в том же хранилище - Это практически с 2 различных хранилищ, за исключением, что они клонировать одновременно. Слияние между двумя ветвями не имеет никакого смысла, поэтому на самом деле нет никакого преимущества в сохранении источника для обоих проектов вместе. Не делай этого.
• Один репозиторий; Различать во время сборки - Храните один репозиторий в одной ветке master, содержащей 2 сборки. Вы можете либо построить проект A, либо проект B из того же источника. Любые функции, использующие источник, будут буквально строить из одних и тех же файлов. Каждый раз, когда вы вносите изменения, вы должны убедиться, что оба сборника все еще работают и что ваши изменения для одного проекта не нарушали другого. Поскольку вы используете только один проект, управление версиями, освобождение и разветвление проще.
• Один репозиторий; Различать во время выполнения - Как и раньше, только вместо двух отдельных сборок есть одна сборка, которая создает один вывод сборки. Функции могут быть включены и отключены во время выполнения. Вы можете сделать это через меню, конфигурационный файл или схему лицензирования, если вы не будете продавать их как разные продукты.

• Три репозитория - У вас есть 2 результата и некоторый общий код, который они разделяют. Разбейте этот общий код в отдельную библиотеку, которую вы также поддерживаете. Вы тогда граф зависимостей так:

  +-----------+ +-----------+ 
  | Project A | | Project B | 
  +-----------+ +-----------+ 
       \  /
        \  /
       +----------------+ 
       | Common Library | 
       +----------------+ 
  

Оба проекта А и Б Проект зависит от общей библиотеки. Вы можете управлять этой зависимостью разными способами (управление зависимостями - это огромная тема сама по себе). Общая библиотека может иметь сборку, которая где-то публикует артефакт, который позже может быть использован сборками для проектов A и Project B. В качестве альтернативы вы можете построить с источником библиотеки в подкаталоге каждого проекта. Git Submodules может помочь с этим подходом.