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

Скажімо, у мене є проект, який містить декілька компонентів: компонент сервера, компонент веб-додатків, компонент iOS, компонент Android тощо. Ці компоненти є усі окремими кодовими базами, але також нещільно пов'язані (наприклад, зміна сервера код може вимагати змін і для всіх інших компонентів)

Який найбільш ефективний спосіб організувати цей проект у Git? Якщо ви помістите все це в одне сховище, у вас завжди будуть найновіші версії, але все стає досить брудним, коли ви починаєте змінювати один компонент, а не інші.

З іншого боку, якщо ви робите кожен компонент окремим сховищем, як би ви змогли "зв’язати" ці сховища, щоб ви знали, що версія 2.0 додатка вимагає версії 1.5 компонента сервера тощо?

Чи є функція в git поза тим, щоб постійно оновлювати ремеди (чи якесь краще рішення, яке я не бачу), щоб більш ефективно керувати кількома пов'язаними репортажами?

Підпроекти - це місце, де розповсюджені системи управління версіями (DVCS) починають, якщо не розгадувати, то, звичайно, стануть трохи химерними.

Git підмодуль і Mercurial subrepositories обидва націлені на підтримку суб-проекту. Обидва покращили випуск за версією (до того, що стара "Mercurial" ця функція існує, але ви, мабуть, не повинні її використовувати "попередження більше не спереду.)

Тим не менш, багатопроектні репозиції залишаються скоріше випадком використання спеціальності, а не всім, хто використовує його. Документація містить численні застереження та інструкції "як це використовувати", в яких чітко видно, що управління "проектами проектів" є проблемою на двох рівнях, метаменеджмент трохи, але по-справжньому відрізняється від прямого однорівневого управління проектами. Як результат, тут набагато менше досвіду. І не бракує "не використовуйте підмодулі git!" і "уникайте меркуріальних субрепостів!" коментарі та публікації в блозі.

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

Це не означає, що управління підмодулями / субрепостами не допоможе вам, але це щось, що потрібно робити обережно, і, безумовно, попередні експерименти та планування.

Зважаючи на те, що ви зосереджені на Git, ви також повинні вивчити підряди Git, які деякі вважають кращою альтернативою підмодулям git .

Якщо ви використовуєте C #, ви можете використовувати NuGet.

Зробіть кожен компонент бібліотекою та зберігайте їх у власному сховищі. Зробіть випуски основних компонентів, які ви версуєте, відповідно до семантичної версії.

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

Той самий базовий підхід (залежність версії та пакета) може бути використаний і в інших мовах, але може бути не таким зручним.

Я б не рекомендував вам використовувати підмодулі Git. Хоча теоретично його можна використовувати для подібних питань, я вважаю, що це більше клопоту, ніж варто.

На мою думку, це залежало б від того, наскільки вони насправді пов'язані. Це дійсно приємно мати можливість запускати автоматизовану git bisectпід час відстеження регресії, але це буде важко зробити, якщо кожен виклик залежить від іншої версії інших ваших залежностей, яку потрібно виконати.

Двома можливими варіантами буде одне сховище з підмодулями або декілька сховищ із належними методами версій.

як би ви змогли "зв’язати" ці сховища, щоб ви знали, що версія 2.0 додатка вимагає версії 1.5 серверного компонента тощо?

Зазвичай це область якоїсь структури управління залежностями (наприклад, Gradle, Maven), а не сам Git.