Как структурировать репозитории git для проекта?


9

Я работаю над модулем синхронизации контента для 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 хранилища - одно для клиента и другое для сервера.

Ответы:


7

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

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

Более того, вы всегда можете переключиться на несколько репозиториев: просто клонируйте репо и удалите ненужные ветки. Обратный путь труднее.

Я бы сделал несколько репо, только если сервер и клиент ничего не делят или если код действительно огромный.


Я собираюсь пойти по этому пути, потому что Drupal хранит разные версии как ветки. Я тоже +1, но нужно 15 повторений!
Литтлединамо

4

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

В случае больших изменений я бы просто создал новые репозитории. Определенно нет разных веток для них. Хотя ветки являются мощными для реализации новых функциональных возможностей и, возможно, одной постоянной ветки развертывания, я всегда избегаю слишком большого количества параллельных операций в течение длительного времени. Вы всегда должны будете поддерживать их (делать ребазировки, когда основная ветвь изменилась и т. Д.), Поэтому сохраняйте базовое структурирование как можно более простым. Наличие дополнительного репо (по моему скромному мнению) менее болезненно, чем жонглирование веток в разных штатах. Особенно, если клиент и сервер не разделяют много кода.

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


1
Спасибо. Это интересно, потому что я только что обнаружил, что модули Drupal Core хранят отдельные версии как ветки. Я думаю, что для меня имеет смысл подражать этой структуре. Я бы +1, но нужно 15 представителей!
Литтлединамо
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.