Рекомендуемое структурирование репозитория git

Question

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

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

So, Project 
    repo1 -> Component A (PHP) 
    repo2 -> Component B (NodeJS) 
    repo3 -> Component C (NodeJS) 
    repo4 -> Component D (JAVA) 

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

Я хочу, чтобы достичь следующего:

• Каждый из этих компонентов будет находиться на разных серверах
• Удобство в дальнейшем развитии и ОБСЛУЖИВАНИЕ
• Крючки для автоматического развертывания компонентов для своих серверов

Какова рекомендуемая структура git/рабочий процесс для этого?

_{Примечание:
Всех кодовый по-прежнему местная.
Я попытался использовать поддерево, и теперь у меня есть один проект, который сохраняет все коммиты от других компонентов, я не уверен после использования поддерева, если в будущем можно будет разделить модуль на отдельный git-репо. (Я слышал notgood things о дополнительных модулях, поэтому еще не пробовал).}

Answer 1

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

Если есть изменения в одном компоненте, которые влияют на другого, используйте какое-то управление версиями API, чтобы справиться с этим; убедитесь, что когда вы делаете несовместимое изменение в одном, вы обновляете номер версии, чтобы, если кто-то тянет именно это, а не другое, они сразу узнают, что пошло не так.

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

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

Какой бы вы ни выбрали, не беспокойтесь об этом слишком много. Одна из приятных вещей в Git заключается в том, что довольно легко слить или разделить репозитории позже, когда вы поймете, что сделали это неправильно. Если вы попытаетесь разделить подход, и он заканчивается слишком запутанным или громоздким, выполните слияние поддерева, и теперь у вас есть единый репозиторий. Если вы попробуете унифицированный подход, и он становится слишком большим?Запустите git filter-branch над ним, чтобы выделить каждый из подкаталогов для подкомпонентов, и теперь у вас есть несколько независимых репозиториев (в этом случае сохраните оригинал, так что у вас действительно есть полная объединенная история, если это станет актуальным в будущем) ,