Группировка нескольких Git-репозиториев, которые являются частью одного и того же общего проекта

Допустим, у меня есть проект, который имеет несколько компонентов: компонент сервера, компонент веб-приложения, компонент iOS, компонент Android и т. Д. Все эти компоненты являются отдельными кодовыми базами, но также слабо связаны (например, изменение на сервере). код может потребовать изменения всех других компонентов тоже)

Какой самый эффективный способ в Git организовать этот проект? Если вы поместите все это в один репозиторий, у вас всегда будут самые последние версии, но все становится довольно грязно, когда вы начинаете менять один компонент, а не другие.

С другой стороны, если вы сделаете каждый компонент отдельным репозиторием, как вы сможете «связать» эти репозитории, чтобы вы знали, что для версии 2.0 приложения требуется версия 1.5 серверного компонента и т. Д.?

Есть ли в git какая-то функция, кроме того, чтобы поддерживать актуальность readmes (или какое-то лучшее решение, которого я не вижу) для более эффективного управления несколькими связанными репо?

Подпроекты - это место, где распределенные системы контроля версий (DVCS) начинают, если не рушатся, безусловно, становятся немного вялыми.

Git submodules и Mercurial subrepositories обе предназначены для поддержки подпроектов. У обоих улучшен выпуск за выпуском (до такой степени, что старая функция Mercurial «эта функция существует, но вы, вероятно, не должны ее использовать», предупреждение больше не является передним и центральным.)

Тем не менее, многопроектные репозитории остаются в большей степени специализированным сценарием, а не функцией «все используют». Документация содержит многочисленные предостережения и инструкции «как использовать это», которые ясно показывают, что управление «проектами проектов» представляет собой двухуровневую задачу, а метауправление немного, но действительно отличается от прямого, одноуровневого управления проектами. В результате, там гораздо меньше опыта. И нет недостатка в «не используйте подмодули git!» и "избегать ртутных подпунктов!" комментарии и сообщения в блоге.

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

Это не означает, что управление подмодулями / подпунктами не будет работать для вас, но это то, что должно быть сделано с осторожностью, и, безусловно, некоторые предварительные эксперименты и планирование.

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

Если вы используете C #, вы можете использовать NuGet.

Сделайте каждый компонент библиотекой и храните их в своем собственном хранилище. Делайте выпуски основных компонентов, которые вы создаете, в соответствии с семантической версией.

Наконец, попросите ваш сервер сборки упаковать библиотеки в пакеты NuGet и использовать эти пакеты NuGet в проектах для интерфейсных компонентов (iOS, Android).

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

Я бы не рекомендовал вам использовать Git Submodules. Хотя теоретически это можно использовать для решения подобных проблем, я чувствую, что это намного сложнее, чем стоит.

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

Два возможных варианта - это один репозиторий с подмодулями или несколько репозиториев с хорошей версионностью.

Как бы вы могли «связать» эти репозитории, чтобы вы знали, что для версии 2.0 приложения требуется версия 1.5 серверного компонента и т. д.?

Обычно это область некоторой структуры управления зависимостями (например, Gradle, Maven), а не сам Git.