Flusso di lavoro per l'utilizzo di git submodules in Visual Studio

Question

Ho un codice condiviso che desidero condividere con un numero di soluzioni. La maggior parte degli esempi usa la riga di comando, ma voglio farlo usando Visual Studio 2013 (e/o TortoiseGit)?

- SolutionShared 
    - .git 
    - Project1Shared 
    - Project2Shared 
- Solution1 
    - .git 
    - ProjectFoo 
    - ProjectBar 
    - [SolutionShared] 
    - [Project1Shared] 
    - [Project2Shared] 
- Solution2 
    - .git 
    - ProjectBaz 
    - ProjectQux 
    - [SolutionShared] 
    - [Project1Shared] 
    - [Project2Shared] 

Quello che ho fatto è stato quello di creare una nuova soluzione SolutionShared, aggiungere tutto il mio codice condiviso lì, e aggiungerlo al proprio git repo. Quindi ho usato TortoiseGit (dato che non riuscivo a capire come farlo Visual Studio) per aggiungere quel repository condiviso come sottomodulo git a Solution1 e Solution2.

1. Che cosa faccio in Visual Studio?
Le mie due soluzioni ora hanno una directory SolutionShared. Aggiungo semplicemente i suoi due progetti figlio (Project1Shared e Project2Shared) in Visual Studio?

2. Come faccio a fare modifiche al codice condiviso all'interno dei progetti non condivisi
Se sono in una delle soluzioni non condivise e apporta una modifica a qualcosa nel modulo, come si fa Mi impegno e lo riporto al repository della soluzione condivisa (SolutionShared) in modo che sia disponibile per tutte le soluzioni che lo fanno riferimento?

Answer 1

Dopo tanto sperimentare ...

In VS, aggiungere i progetti condivisi dal modulo alla soluzione. Sembrano vivere "al di fuori" della soluzione genitore per quanto riguarda il controllo delle versioni.

Se si effettua una modifica ai progetti del sottomodulo, sono locali. Devono essere impegnati e spinti al repository di origine, e quindi è necessario unirli lì. Se apporti modifiche all'origine, devi inserirle manualmente nel sottomodulo git della tua soluzione.

Il problema è che VS non fa nulla per te, quindi devi usare qualcosa come TortoiseGit o la riga di comando.

Answer 2

Abbiamo trovato che il modo più semplice per farlo è spostare ciascuna delle nostre unità di codice condivise nel proprio progetto Visual Studio e inserire ogni progetto di Visual Studio condiviso nel proprio repository.

Quindi aggiungiamo ognuno di questi progetti come sottomodulo a qualsiasi soluzione che ne abbia bisogno. Questo è utile poiché molti dei nostri progetti possono essere di dimensioni molto grandi e condividere molti degli stessi pezzi di codice. Abbiamo fatto ampio uso di pacchetti di nuget per questo scopo, ma in genere abbiamo avuto un migliore successo e una migliore esperienza di progettazione/debug con i sottomoduli.

Molto è cambiato in Microsoft in relazione a Git negli ultimi anni. Visual Studio Team Services (TFS Online) e On Prem-TFS (dal TFS2015) ora hanno una buona conoscenza di come funzionano i sottomoduli e ora possono fare build CI che incorporano i sottomoduli fin da subito.

Il supporto in TFS 2015 on-prem è tuttavia un po 'problematico. I riferimenti di TFS Build ai sottomoduli hanno l'abitudine di diventare corrotti, con il risultato di build che smettono di funzionare senza preavviso fino a quando il sottomodulo non è completamente rimosso e riaggiunto - non è un processo divertente. Per questo motivo (tra pochi altri), stiamo utilizzando VSTS (TFS Online) per tutto e non abbiamo avuto nessuno degli stessi tipi di problemi. Suppongo che questo sia stato risolto anche in TFS 2017 on-prem.

Come è stato menzionato, Visual Studio stesso (l'IDE) ha ancora difficoltà a comprendere le relazioni dei sottomoduli. Non è davvero in grado di gestirli. Ho provato un numero di Git Tools standalone per trovare il modo più semplice per gestire un ambiente come questo. Tortoise sembra fornire l'esperienza più semplice e più performante quando si spinge, si tira e si effettua il check-in per i repository contenenti i sottomoduli. Di solito uso i comandi per aggiungere i sottomoduli, ma ho il sospetto che la funzionalità di aggiunta del sottomodulo di Tortoise funzioni altrettanto bene.

Quando si esegue il commit di codice su un repository utilizzando Tortoise, viene visualizzato quando un sottomodulo è sporco e viene richiesto di effettuare il check-in del sottomodulo prima di effettuare il check-in del repository padre. È molto carino. Tirare o recuperare il repository padre può essere un po 'di confusione, però. In realtà non aggiorna il sottomodulo dal suo ramo remoto, lo aggiorna solo a qualsiasi livello attualmente controllato nel telecomando principale del repository che non è sempre l'ultimo. In realtà, questo è il comportamento desiderato, non è immediatamente intuitivo se non te l'aspetti.