Як структурувати сховища git для проекту?

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

Сервер створений на Drupal 6. Клієнт створений на Drupal 7. Існує потреба у версії сервера Druapl 7. І тоді вийде потреба у версії Drupal 8 як клієнта, так і сервера, як тільки він вийде наступного року.

Я досить новачок у контролі git та джерел, тому мені було цікаво, який найкращий спосіб налаштувати сховища git? Чи може це мати окремий сховище для кожного примірника, тобто:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

Або було б більше сенсу мати одне сховище для сервера, а інше для клієнта, а потім створити гілки для кожної версії Drupal?

На даний момент у мене є 2 сховища - одне для клієнта та інше для сервера.

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

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

Крім того, ви завжди можете переключитися на кілька сховищ: просто клонуйте репо і видаліть гілки, які ви не хочете. Їхати навпаки складніше.

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

Я бачив і працював з такими варіаціями. Все в одній папці з вкладеними папками для сервера та клієнта або по одному репо. Я віддаю перевагу єдиному репо для кожної основної частини проекту.

У разі великих змін версії я просто створив би нові репости. Однозначно не мати для них різних гілок. Хоча гілки є потужними для впровадження нових функціональних можливостей і, можливо, одна гілка постійного розгортання, я завжди уникаю того, щоб занадто багато з них тривалий час працювали паралельно. Вам завжди доведеться підтримувати їх (робити скидки, коли змінилася головна гілка тощо), тому зберігайте основні структури максимально просто. Маючи додатковий репо - на мою скромну думку, менш болісно, ​​ніж жонглювати гілками в різних штатах. Особливо, якщо клієнт і сервер не ділять багато коду.

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