Зависимость Github для файла решения

Question

Я не уверен, что лучший способ описать это - я сделал какой-то поиск в Google, но на avail.

я в настоящее время есть решение, которое имеет следующее:

Repository 1 ProductProject1 ProductProject2 ProductProject3 SharedCodeProject1 SharedCodeProject2

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

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

Мне любопытно, как другие управляют этим типом ситуации? Просто разрешите разработчикам клонировать весь репозиторий так, как я был?

Мой Предложенное решение было ...

Возможное решение 1

установки отдельных репозиториев так:

Repository1 ProductProject1 SharedCodeProject1 SharedCodeProject2

Repository2 ProductProject2 SharedCodeProject1 SharedCodeProject2

Repository3 ProductProject3 SharedCodeProject1 SharedCodeProject2

Pro: Код компактнее и только обнажает Дев к ProductProject они несут ответственность за

Con: Подумав это до конца, я понял, что SharedCodeProject1 и SharedCodeProject2 будут в основном смешались версии через каждый репозиторий , когда на самом деле они должны и могут просто оставаться одинаковыми во всех.

Возможное решение 2

установки отдельных репозиториев так:

Repository1 ProductProject1

Repository2 ProductProject2

Repository3 ProductProject3

Repository4 SharedCodeProject1 SharedCodeProject2

Плюсы: Честно говоря, я даже не уверен, возможна ли эта структура, так как в репозиториях 1 - 3 будет тонна неработающих ссылок (если нет каких-то магических установок, о которых я не знаю) теоретически бонус заключается в том, что SharedCodeProject1 и 2 централизованы, поэтому любой разработчик, который обновляет все разработчики, получает и может повторно использовать эти обновления (в частности, для уровня БД, который является одним из совместно используемого проекта и бизнес-логики, который находится в другом проекте общего кода)

Минусы: ломая изменения не реализованы не будут действительно быть реализованы во всех хранилищах до синхронизации (это имеет смысл)

Мне очень сложно найти лучший способ сделать любую из этих работ. Надеюсь, это имеет смысл, пожалуйста, дайте мне знать, если я смогу прояснить ситуацию.

Мне просто интересно, как другие компании строят большие решения на github, как это, пытаясь ограничить доступ к разработчикам только для конкретных проектов.

Спасибо большое!

Answer 1

Ну, вот моя идея сделать это в разных репозиториях еще в основной системе, которая может быть использована для тестирования совместимости, только git клонирует их все, а затем вы можете проверить совместимость. Hech просто напишите файл .sh, чтобы клонировать их, когда вы хотите проверить.

Answer 2

Вы должны перенести все свои Продукты, чтобы разделить Хранилища, а также ваш Общий код. Общий код должен быть в собственном репо, из которого вы копируете и создаете пакет Nuget.

Затем вы можете добавить этот пакет Nuget в репозиторий Nuget (может быть просто сетевым ресурсом, но встроен в TFS и VSTS), из которого вы можете добавить его в качестве ссылки на свои продукты.

Когда вы вносите изменения в общий код, вы создаете тестируемую версию и развертываете ее в своем решении по управлению пакетами. Когда ваши разработчики откроют свой проект, им будет предложено обновить до последней версии пакета. Таким образом, если у вас есть релиз и вам необходимо отправить Product1 с v1.2 зависимости, чтобы свести к минимуму риск, даже если новый v2.0 этого общего компонента отправлен.

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

Answer 3

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

Я думаю, что вы действительно должны думать о том, что перед разрезанием репозиторий в нескольких хранилищах ...

Разве вы не можете просто использовать несколько SLN файлы и поместить некоторое доверие в ваших developpers делать правильные вещи?

Существует движение, что посоветуете для использования только один репозиторий, и что есть хорошие вещи, чтобы принять от него ... Смотрите «monorepo» на Google (Facebook и Google используют его) Одна ссылка на него: http://danluu.com/monorepo/

Другим способом является создание нескольких репозиториев и создание пакетов nuget для управления зависимостями.