Cambio di squadra da TFS Source Control a TFS con Git, non so come gestire la complessa struttura di progetto

Dipende da quanto strettamente accoppiati sono i moduli. E soprattutto quanto strettamente sono in termini organizzativi .

Tutti i moduli sviluppati dallo stesso team nel contesto dello stesso progetto (nel senso gestione della parola) dovrebbero probabilmente andare in un repository, specialmente se è possibile che un cambiamento logico si estenda più di uno di loro.

I moduli sviluppati separatamente, dovrebbero vivere in repository separati. Ma ci dovrebbe anche essere almeno un processo di rilascio semi-formale per fornire i risultati di un progetto all'altro. Non a causa di git, ma per ridurre l'overhead della comunicazione soprattutto quando un cattivo commit in un progetto interesserebbe molte persone in altri progetti.

Git lavorerà allegramente con centinaia di migliaia di file. Funzionerà se dividi o se non lo fai. Quindi la decisione di dividere è organizzativa. Volete un po 'di barriera tra le squadre in modo che gli errori non influenzino troppe persone e volete team ragionevolmente piccoli per limitare il sovraccarico della comunicazione (20 persone sono piuttosto grandi team).

TFS tratta tutto come un singolo repository, quindi non si può fare molto male a partire da tutte le cose in un singolo repository git mantenendo la struttura precedente. O dividendo solo gli elementi ovviamente disgiunti.

Puoi dividere il grande repo con la sottostruttura dopo-il fatto che in qualsiasi momento conservi la cronologia.

Avere un singolo repository ha molti vantaggi effettivi e a meno che la dimensione del clone non sia considerata pertinente, gli svantaggi sono facili da mitigare.

Se inizi con più repository hai immediatamente bisogno di qualche strumento per sincronizzarli tutti per il recupero e taggare tutti sui punti di rilascio. Anche spostare codice in giro è scomodo (dall'app alla libreria condivisa, dovrebbe essere comune e diretto).

Certo, puoi combattere con i sottomoduli, o qualcosa di simile, ma molte persone li trovano tenuti come ultima risorsa.

Siamo passati da tfs a git un anno e mezzo fa, ho creato un repository bin per componenti esterni, uno per "dati" e conservato tutte le fonti create con VS in un repository. Solo dividendo le fonti Fortran su cui un programmatore sta lavorando e lui ha un repository bin per rilasciare l'output - che completa il repository bin. E ho immediatamente scritto uno strumento in python che conosce tutti i repository (abbiamo anche installer, test, strumenti, ecc.) E consente le operazioni di base (fetch, status, synch) e, cosa più importante, che "crea" la copia dell'ambiente di sviluppo l'esterno include, libs, dlls ...

Il repository di origine ha alcune righe di codice di 1,6 milioni in ~ 4000 file e ~ 90 progetti. Non ho intenzione di dividerlo. Il repository e i repository di dati sono per fortuna piuttosto freddi. Ancora poche volte è stato PITA a tornare indietro con le fonti e dover tornare indietro manualmente con gli altri bisecando un problema.

Ah, i vecchi "progetti condivisi" .. per coloro che non usano TFS (o VSS) puoi creare una sorta di link simbolico all'interno del repository così un singolo progetto sembra essere in 2 posti contemporaneamente. Questo è ciò che viene usato qui.

A mia conoscenza, nessun altro SCM ha questa funzione. IMHO questa è una buona cosa in quanto ti fa pensare a ogni progetto come a un'entità indipendente e non a confonderlo all'interno di progetti - penso che la sua unica utilità sia se il tuo IDE non gestisce bene i riferimenti esterni ...

Quindi, se vuoi migrare, devi dividere questi progetti condivisi in una diversa struttura di progetto e costruirli separatamente. quindi cambia i tuoi progetti in modo che costruiscano con riferimenti ai sotto-progetti. Non cercare di mantenere la stessa mentalità di mantenere questi progetti nella struttura esistente albero / soluzione. Le tue soluzioni non saranno in grado di contenere tutti i progetti al loro interno. MS ha alcune linee guida per l'organizzazione del tuo SCM , dovrai spostarti dalla 'soluzione partizionata 'modella al modello' soluzioni multiple '.

dovrai gestire le dipendenze tra i progetti, ma non è così difficile se hai un buon sistema CI che costruirà una catena di dipendenze quando 1 modifiche (consiglio Jenkins, è potente ma molto più semplice di quanto non sia possibile la build basata su xaml TFS2012 ora usa)