Estoy trabajando en un equipo de software que consta de 4-5 desarrolladores que trabajan en un solo proyecto TFS. Estamos considerando mover todo el código base a GIT. El código base consta de aproximadamente 50 soluciones de Visual Studio (2013) divididas en aproximadamente 300 proyectos. El procedimiento preferido para hacer referencia a otro conjunto en un proyecto ha sido agregar el proyecto a la solución y así sucesivamente. Supongo que esto se considera un poco desordenado, pero tiene sus ventajas:

1: Dado que el código fuente se actualiza a más reciente, los proyectos siempre se actualizarán con lo último cuando se construyan.

2: Cuando se crea una rama de lanzamiento, se almacena la imagen completa del estado de las fuentes, y es posible reproducir el lanzamiento fácilmente si (cuando) es necesario.

Al considerar la migración a GIT, la forma más sencilla sería simplemente mover todas las soluciones y proyectos, más o menos a un solo repositorio de GIT. Esto me lleva a mi primera pregunta.

¿Será difícil trabajar con una colección de más de 50 soluciones divididas en 300 proyectos en un solo repositorio de GIT? Tengo miedo de perder una visión general de los cambios realizados por cada desarrollador a diario.

Otro enfoque, y creo que esta es la forma correcta, es alejarse del régimen de proyectos compartidos y dividir el código base en partes lógicamente divididas con sus propios repositorios GIT. (Supongo que esto nos dejaría con unos 10-20 repos). Para resolver los proyectos a los que se hace referencia en este asunto, estamos considerando usar un servidor nuget local.

Esto me lleva a mi segunda (y última) pregunta. Echa un vistazo a los beneficios mencionados anteriormente. ¿Se pueden mantener estas características? ¿Podemos "actualizar automáticamente" las referencias de nuget en la rama de trabajo, pero congelarlas a una versión específica en una rama de lanzamiento?