Как организовать совместную разработку нескольких проектов в git?
Есть несколько проектов. Каждый проект делается под своего заказчика, причем у все проектов есть ядро, модули и конкретные настройки. Каждому заказчику попадают свои модули, часто модулей идет нескольким заказчикам, часть всем, часть - строго индивидуально.
Проект 1 (ядро модуль1 модуль2 модуль3 модуль4 модуль5)
Проект 2 (ядро модуль1 модуль2 модуль6)
Проект 3 (ядро модуль1 модуль4 модуль7)
Проект 4 (ядро модуль2 модуль3 модуль4 модуль8)
Проект 5 (ядро модуль1 модуль9)
Каким образом организовать git репозиторий, что бы обеспечить
а) совместную разработку всех общих частей (ядра, общих модулей)
б) недопущение попадания кода из одного проекта в другой
p.s. можно подпроектами, но выделять под каждого заказчика или под каждый модуль отдельный проект не хочется.
Я бы на сабмодули посмотрел https://git-scm.com/book/en/v2/Git-Tools-Submodules
если ядро у всех заказчиков одинаковое, я бы включал его как сабмодуль в репозиторий заказчика
По факту - один заказчик - одна репа
Каждый модуль - своя репа
Конфигурация и набор модулей определяется в репе для заказчика
За конкретные версии сабмодулей в репе щакащчика отвечает человек, который обеспечивает доставку версии для заказчика.
Можно использовать не сабмодули гита, а механизм модулей самого языка (npm в javascript например)
всем кто советовал разделять на модули: не вариант. я сразу написал об этом (правда назвал их подпроектами).
слишком уж много геморроя. На добавление файла с 20 строчками мне требуется создать 2 новых репы. но прелесть начинается потом - например ядро получается в 100500 копиях (свое в своем локальном проекте).
после внимательного изучения гита я нашел решение наиболее подходящее для моей задачи - это sparse checkout
p.s. а для дистрибуции я решил использовать множественные репозитории для 1 проекта (указывая --git-dir).
т.е. при необходимости провести деплой конкретного проекта (через git причем что бы на сервер заказчикак никак не попадал "левый" код), я из рабочего sparse checkout делаю репозиторий .git-"имя проекта"
А почему множественные репозитории, а не множественные рабочие каталоги?
Продукт дистрибуции же конечный продукт, собранный из выбранных модулей и лежащий в папке.
А ваши множественные репозитории всё равно содержат в себе все модули и фактически одинаковы.
Antonio Solo, ну вот если следовать примерам из блога GitHub, в корне проекта кидаем некий скрипт для распаковки из репозитория в рабочий каталог нужного комплекта модулей. В зависимости от параметров, скрипт создаёт нужную конфигурацию.
Нет нужды держать копии самого репозитория.
Сделать для каждого модуля свой репозиторий, в отдельной ветке репозитория для модуля хранить ядро.
Получится что разработчики разрабатывающие общий модуль будут иметь только этот модуль.
Разработчики разрабатывающие ядро (как я понимаю, оно индивидуально для каждой пары модулей), будут иметь доступ только к ядру модулей.
1. Для общих частей создаём отдельный репозиторий и используем какой-нибудь механизм для доставки собранных модулей. (для C#, например, это будет приватный nuget feed).
2. Для каждого нового заказанного проекта - новый репозиторий, к которому подключаются модули.
3. Для каждого нового модуля (если предполагается переиспользование) - новый репозиторий.
Если возникнут проблемы с работой с большим количеством репозиториев - объединить в монорепо ядро и модули.
Для подключения одного репозитория к другому - можно использовать механизм git submodules, но с этим могут возникнуть проблемы
PS: хотелось бы уточнение, что понимается под проектом, ядром, и модулями. И на каком стеке технологий происходит работа - тогда смогу подсказать конкретные технологии, с которыми можно всё упростить.
стек - питон, джанго , +немного php
проект - веб-сайт
ядро - вся общая часть
модуль -специфичный для заказчика код, например обмен с 1С, с другим сайтом, какое-то API, парсинг поставщика и т. д. дизайн.
Исходники проекта, ядра и модулей - это одно. Бизнес-проекты, для которых собираем билды из первых - это иное. Git - это система контроля версий исходного кода, она не занимается решением вопросов бизнеса. Поэтому не стоит через git решать вопросы кому какие модули были проданы.
Если смотреть шире, то пусть разработчики пишут код (в одном репе, в нескольких репах: ядро и модули, как вам удобнее). А в каком виде собирать билд очередному заказчику пусть решают и делают другие люди (а если даже и те же, то все равно в рамках совсем иного процесса).
Antonio Solo, если речь про сборку билда используйте что лучше знаете и к чему привыкли. Но, опять же, что собираете, если это пакеты для ОС, то там классически принято использовать make.
Каждый проект свой git реп с submodules (ядро + модули)
Разработку во всех репах вести по методологии gitflow: master (или release), ветка develop (является родительской для мастера), фичаветки (активная разработка фич, фик и т.д.). С фичаветки в девелоп, проверяем, сливаем в мастер. Заказчику уходят только мастера репов!
Главное грамотно разделять на модули! И наверное придётся следить за таким моментом: в модуль добавили фичу, которая требует поравить ядро. Необходимо перед деплоем убедиться, что модуль и ядро соответствуют! На 5+ модулях это делать в ручную уже так себе!
Удачи!
