Я работаю в команде разработчиков программного обеспечения, которая состоит из 4-5 разработчиков, работающих в одном проекте TFS. Мы рассматриваем возможность перемещения всей кодовой базы в GIT. База кода состоит из около 50 решений Visual Studio (2013), разделенных на около 300 проектов. Предпочтительной процедурой ссылки на другую сборку в проекте было добавление проекта в решение и так далее. Я предполагаю, что это считается немного грязным, но у этого есть свои льготы:

1: Учитывая, что исходный код обновлен до последней версии, проекты всегда будут обновляться до последней версии при сборке.

2: Когда создается ветвь релиза, сохраняется полная картина состояния источников, и можно легко воспроизвести релиз, если (когда) это необходимо.

При рассмотрении вопроса о переходе на GIT проще всего было бы просто перенести все решения и проекты, почти как в одно репозиторий GIT. Это приводит меня к моему первому вопросу.

Трудно ли будет работать с подборкой из 50 или более решений, разделенных на 300 проектов в одном репозитории GIT? Я боюсь потерять обзор изменений, вносимых каждым разработчиком ежедневно.

Другой подход, и я думаю, что это правильный путь, состоит в том, чтобы отойти от режима общих проектов и разделить кодовую базу на логически разделенные части с их собственными репозиториями GIT. (Я предполагаю, что это даст нам около 10-20 репо). Чтобы решить упомянутые проекты в этом вопросе, мы рассматриваем возможность использования локального nuget-сервера.

Это подводит меня ко второму (и последнему) вопросу. Взгляните на льготы, упомянутые выше. Можно ли сохранить эти функции? Можем ли мы «автоматически обновить» ссылки на nuget в рабочей ветке, но заморозить их до определенной версии в ветке релиза?