Структурирование связанных компонентов в git

Question

Моя команда рассматривает возможность перехода от 2 дюжин репозиториев Subversion к репозиториям Git.Что мы пытаемся исправить, так это то, что в настоящее время у каждого есть свои собственные репозитории Subversion для каждого из компонентов продукта.То, что я хотел бы сделать, это попытаться уменьшить разрастание, которое у нас есть, и помочь построить четкий путь вперед.

Я ищу совет о том, как структурировать репозитории.Одним из вопросов является то, как группировать связанные проекты.У нас есть два продукта.Каждый продукт имеет набор кода веб-сервисов (php), код клиента Android (java), код клиента iphone (obj c), код ipad (obj c) и код клиента веб-сайта (php + js).В настоящее время каждый владелец имеет свой компонент в отдельном репозитории svn.

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

Answer 1

Критериями для объединения разных наборов файлов в одном «компоненте» (здесь одно Git-репо) является их соответствующий жизненный цикл разработки (способ, которым они развиваются в терминах маркировки и ветвления):

• можетвы делаете эволюцию на php или java-модуле, не внося никаких изменений в другие модули (например, obj c)?
• можете ли вы выделить в ветке некоторые изменения / исправления, которые сделаны только для one из этих модулей, а не других?
• Вы можете повторно использовать конкретную версию одного из этих модулей в нескольких проектах?

Если да, подход на основе компонентовлучший (то есть одно git-репо на модуль), в отличие от одного репо со всем в нем ( системный подход ).
См., например, " Компонентно-ориентированный макет каталога веб-проекта с git и символическими ссылками ".

Компонент представляет собой" согласованный набор файлов "и лучше всего управляется в своем собственном репозитории Git.

Answer 2

У вас есть как минимум два варианта:

• Подмодули
• Слияние поддеревьев

ЕслиВаши проекты в основном частные, я бы порекомендовал вам придерживаться первого.Читайте документы, это все легко.

Answer 3

Я не знаю много о рабочих процессах Git, но знаю, что у вас есть как минимум три варианта:

1. Для каждого проекта свой репо , вероятно, самый безопасный вариант. Тэги и хорошие инструменты тестирования - ваши друзья.
2. Отдельные ветви для каждой группы проектов и для каждого проекта, его собственная ветвь . Обязательно сделайте резервную копию, прежде чем делать это. Смотрите видео Скотта Чакона о пустых ветвях. Я не делал этого раньше, но ветки Gh-страниц Github - живой пример.
3. Подмодули . Каждый проект получает собственное git-репо, внутри самого git-репо . Наверное, лучшая идея вокруг.