Как ораганизовать репозиторий для команды?

Question

[Андрей Корехов]

Добрый день.

Есть команда из нескольких человек. Требуется организовать совместную работу с контролем через гит.
Мне в целом понятно как работать группой над одним проектом, но специфика решаемых задач в том что проектов много и одновременно над ним работает только часть команды.

Если заводить каждый новый проект через отдельный репозиторий то их становится сложно отслеживать. + дополнительные сложности в том что бы постоянно добавлять и исключать оттуда людей.

Если же заводить один репозиторий в котором по папкам разделяются проекты система в какой то момент превращается в свалку так как в один комит могут попасть данные из разных проектов. Которые вообще то пересекаться не должны.

Кроме того иногда в команду приходят новые люди и пускать их сразу ко всему коду и наработкам компании не хотелось бы - т.е. нужно разграничение доступа.

И как то пазл не складывается =) Хочется и удобно и безопасно и т.д. )
Может кто нибудь подсказать книги / статьи по подобной организации работы ?

Comments

[Сергей Кузнецов]

Попробуйте организовать монорепозиторий. Это не просто свалка разных проектов.

Answer 1

[sheerluck]

Так как приходят новые люди и им нужно показывать только часть кода -- то надо заводить новый отдельный репозиторий. Отслеживать их не сложно. Добавлять и исключать людей не сложно.
А свалку делать не надо.

Answer 2

[Арина Левадная]

Всё же лучше отдельные репозитории.
Или несколько отдельных репозиториев, сгруппированных по функционалу приложения, в которых будут подпапки.
У вас же каждый сотрудник работает в своем форке.
При внимательной организации code review и мержа только по результатам code review большой свалки в проектах и подпроектах быть не должно.

Answer 3

[Илья Голец]

Тут важный вопрос. Общие части системы можно редактировать, или нет?

Если нет — можно вынести их в отдельные репы, собирать из них nuget модули и публиковать в частном nuget репозитории.

Если нужно редактировать и хочется заморочиться, то можно сделать следующее:

1. Сделать репозитории для небольших подсистем
   
2. Для каждого проекта сделать по репозиторию, составить список подсистем, которые в нём используются и
   
3. В репозиторий проекта добавить подсистемы через https://git-scm.com/book/en/v2/Git-Tools-Submodules
   
4. Добавить код, уникальный для проекта в виде отдельных папок в репозитории проекта.
   
5. Постараться не запутаться во всём этом великолепии и не сломать друг другу работу.
   

Ещё есть вариант отказаться от монолита, удариться в микросервисы. Тогда каждый кусок проекта будет независимым и можно будет его вынести в отдельную репу. Но тут может быть много работы по распилу монолита.

Comments

[Андрей Корехов]

Ну у нас в целом и идут как микросервисы.
Спасибо за совет. Изучим вопрос
Решили все тем что подняли свой сервер на Gitea и настроили к нему vpn для сотрудников. Ну а дальше уже разделение доступа через команды и организации.