Git non è un meccanismo di distribuzione. È uno strumento di controllo del codice sorgente distribuito. Stai utilizzando in modo creativo la parte "distribuita" per gestire e distribuire i tuoi artefatti, ma questo non sta giocando alla forza di Git. Invece, la memorizzazione delle risorse binarie è una debolezza di Git, perché
- questo si traduce in una cronologia molto ampia e
- non sono possibili differenze significative.
Ho lavorato con repository di grandi dimensioni contenenti risorse binarie. Questo era inevitabile (perché la raccolta di file binari doveva essere controllata dalla versione), ma è un'esperienza che non consiglio.
È possibile fare un clone superficiale in cui si scaricano solo i commit più importanti, piuttosto che la cronologia completa, ma questo complica l'utilizzo di Git e significa che non si dispone di un repository completo disponibile.
Git è anche uno strumento di distribuzione davvero pessimo, perché Git è preoccupato per i file , non per i processi o servizi in esecuzione sul sistema di produzione . In genere vorrai impostare uno script che possa arrestare e riavviare i servizi pertinenti.
Se la copia dei file in una determinata cartella è sufficiente, quindi scrivi uno script che
- crea un rilascio, quindi
- copia la versione nell'ambiente di produzione con un programma simile a FTP. (Ma non letteralmente FTP, perché trasmette le password in chiaro).
Se hai bisogno di una distribuzione più sofisticata, scrivi uno script che
- crea un rilascio,
- telecomandi nell'ambiente di produzione,
- carica la nuova versione,
- arresta i vecchi processi e si riavvia dalla nuova versione e
- ripulisce le vecchie versioni.
Forse c'è una persona amichevole di Sysadmin o DevOps in giro che può aiutare con questi problemi. Ci sono anche un sacco di soluzioni esistenti appositamente per gestire i tuoi manufatti. Penso che nel mondo .NET, ospitare il tuo repository NuGet sia un approccio comune e decisamente superiore.