Configuración TFS con el repository git compartido en múltiples proyectos

Estoy probando TFS para nuestros proyectos y he encontrado una aparente incompatibilidad con nuestro process de desarrollo actual.

El problema es que tenemos un repository de producto que contiene muchos proyectos de estudio visual (309, sin contar los de C ++). Muchos de estos proyectos se comparten en múltiples soluciones VS (cada solución representa un subsistema).

Me gustaría seguir con esta configuration de repository, pero utilizar un proyecto separado de TFS para cada uno de los subsistemas, de modo que pudiéramos tener sprints separados para cada subsistema.

Hay dos forms en que veo configurar esto:
1. Repositorio TFS GIT compartido para múltiples proyectos TFS
2. Utilice un repository de Git externo y configure cada uno de los proyectos de TFS para usar el mismo repository externo.

He buscado, pero no puedo encontrar si alguna de estas forms es posible.

¿Sabes si esto es un objective alcanzable? ¿Hay algún otro enfoque que deba tratar de satisfacer nuestras necesidades?

Gracias por cualquier ayuda por adelantado.

Puede y debe hacer todo eso en un solo proyecto de equipo.

Si crea un solo proyecto de equipo con Git como SCM, puede crear un repository de Git para cada uno de los subsistemas.

A continuación, puede crear equipos para cada uno de los proyectos / agrupaciones de proyectos / equipos que desee supervisar. Todos sus elementos de trabajo se pueden mantener separados para cada subsistema mediante la ruta de área, al mismo time que le brindan capacidad de acumulación en todos ellos.

http://nakedalm.com/modelling-teams-in-team-foundation-server-2013/

En este post acabo de describir el modelado gerneral disponible con la capacidad del equipo.

http://nakedalm.com/creating-nested-teams-visual-studio-alm/

Y aquí muestro una implementación de ejemplo. Imagine si cada uno de los equipos secundarios son subsistemas.

Cada subsistema puede tener sus propias iteraciones, pero realmente depende de los equipos que tenga. Si tienes 4 equipos que tienen los subsistemas decididos, probablemente solo deberías tener 4 equipos, pero poseen muchas áreas (subsistemas).

También puede optar por utilizar la ruta del área para el equipo y una label para el subsistema. Luego, puede decidir trabajar por acumulación de equipos independientemente del subsistema.

O puede usar la ruta de área para la jerarquía de SubSystems y usar Team Field para denotar equipo.

Mi punto es que dentro de un solo proyecto de equipo se obtiene la flexibilidad para dar forma y remodelar sus atrasos, trabajo, código y personas. En proyectos de equipos múltiples, usted está limitado por el límite del Proyecto del equipo.