В общем, я рекомендую, чтобы проекты оставались отдельными, насколько это имеет смысл (ваш второй вариант). Как правило, это будет способствовать повторному использованию. (Если я хочу только Dependency2, мне не нужно приводить целый другой проект, чтобы добраться до него.)
Однако вы должны быть умны в том, что ваши зависимости действительно будут делать. Например, если Dependency2 равен only и будет зависимостью для Project1, то он, вероятно, должен просто существовать в исходной структуре Project1. (Примечание: я не имею в виду наличие отдельных веток и тегов для зависимости - я имею в виду, что она находится в другом пакете или другом подпроекте в Project1.)
Если вы хотите сделать проект библиотекой многократного использования в вашей организации, то полностью поместите ее в отдельный проект, чтобы не вводить ненужные взаимозависимости. И я бы посоветовал вашей команде разработчиков не проверять зависимость и работать вместе с ней. Вместо этого постройте зависимости и используйте их как двоичную библиотеку. Таким образом, тот, кто проверяет проект для работы с ним, всегда будет иметь самую последнюю библиотечную зависимость, необходимую для приложения. Если требуется обновление, вы можете позаботиться о проверке зависимости и ее создании. (Или, что еще лучше, есть место, где проектные группы могут выпускать новейшие библиотеки в виде двоичных файлов.)
Обновление версий проекта и зависимостей
Если вы идете по маршруту №2, и у вас есть отдельные Project и Dependencies, ваше управление версиями на самом деле становится очень простым. Вот схема того, как это может работать.
- Команда А работает над Проектом 1.
- Команда B работает над зависимостью1, от которой зависит Project1.
- Всякий раз, когда команда B заканчивает свою работу, она создает релиз Dependency1 (двоичный файл - возможно, DLL, или библиотека, или что-то в этом роде). Они также могут пометить свой проект в это время. Двоичное имя может быть: Dependency1-v1.0.0
- Команда A берет двоичный выпуск Dependency1-v1.0.0 и включает его в свой проект. (Как правило, двоичные файлы хранятся в папке / lib или что-то подобное в проекте.)
- Всякий раз, когда команда A заканчивает свою работу, они могут выпустить свой проект и пометить свой проект.
Обратите внимание, что команда A ни в коем случае не извлекает исходный код из Dependency1 и вносит его в свой проект. Это позволяет разрабатывать два проекта независимо друг от друга, так что между группами разработчиков существует автономия. Команда A может использовать бинарный файл так долго или как угодно коротко. Если им нужна обновленная версия, они получают последнюю версию от Team B.
Этот процесс не сильно отличается от того, что вы сделали бы, если бы использовали библиотеку из внешнего источника. Вы не можете контролировать их версию своей библиотеки, поэтому вы просто берете то, что вам нужно для вашего проекта, и обновляете, когда считаете нужным. Вы сохраняете бинарный файл в своей собственной структуре проекта, чтобы вы всегда могли на него положиться.