Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Usare Git per i file di origine, Azure Artifacts per le dipendenze e Git LFS per file binari di grandi dimensioni che cambiano spesso. Se il repository contiene già file di grandi dimensioni, questo articolo consente di decidere cosa conservare in Git, cosa spostare e quando rimuovere i file binari dalla cronologia.
Decidere dove archiviare ogni file
Se decidi cosa fare con i file già presenti in un repository, inizia qui:
- Mantenere i file di origine, gli script e i file di testo in Git.
- Sposta le dipendenze e i pacchetti riutilizzabili in Gestione dei pacchetti di Azure Artifacts.
- Usare Git LFS per file binari di grandi dimensioni che cambiano spesso e per i quali il diff non è efficace.
- Rimuovere file binari di grandi dimensioni dalla cronologia del repository se sono già archiviati e non appartengono più. Vedere Rimuovere file di grandi dimensioni da un repository.
Se il repository è già di grandi dimensioni, esamina il repository e i limiti per il push prima di scegliere una strategia di archiviazione. Vedere Limiti Git per i limiti di file, push e percorso che influiscono sui repository di grandi dimensioni.
Scegliere l'opzione di archiviazione appropriata per Git, la gestione dei pacchetti e Git LFS
Utilizzare questa tabella per scegliere la scelta più adatta.
| Tipo di file o scenario | Utilizzo |
|---|---|
| Codice sorgente, script e file di testo | Git |
| Dipendenze e pacchetti riutilizzabili | gestione dei pacchetti Azure Artifacts |
| File binari di grandi dimensioni che cambiano spesso | Git LFS |
| Azure DevOps Server Git LFS e Kerberos | Vedere le linee guida per Kerberos in questo articolo e l'articolo collegato alla fine |
Git funziona meglio per i file di origine basati su testo e altri contenuti che cambiano in incrementi di piccole dimensioni leggibili.
I file binari di grandi dimensioni non sono adatti per l'archiviazione Git normale perché:
- Git archivia le differenze di versione in modo efficiente per il codice sorgente, gli script e i file di testo.
- I file di grandi dimensioni che cambiano completamente tra una versione e l'altra non si comprimono bene né consentono di confrontare bene le differenze.
- I file binari di grandi dimensioni aumentano i tempi di clone, fetch, branch e checkout.
Se aggiungi file di grandi dimensioni di cui non è possibile visualizzare le differenze, ad esempio file binari, al repository, mantieni una copia completa di tali file nel repository ogni volta che ne esegui il commit con una modifica. Se nel repository esistono molte versioni di questi file, aumentano notevolmente il tempo necessario per l'estrazione, il ramo, il recupero e la clonazione del codice.
Quali file appartengono a Git?
Usare l'opzione più semplice adatta al tipo di file e alla frequenza con cui cambia.
Mantenere il codice sorgente in Git, non le dipendenze
Usare Git per i file modificati direttamente dal team. Mantenere le dipendenze fuori dal repository e distribuirle tramite la gestione dei pacchetti.
- Inserire i file di origine in Git.
- Archiviare DLL, file di libreria e altre dipendenze all'esterno del repository.
- Usa la gestione dei pacchetti per gestire le versioni e distribuire le dipendenze.
La gestione dei pacchetti raggruppa le dipendenze e installa i file nel sistema quando si distribuisce il pacchetto. I pacchetti vengono sottoposti a controllo delle versioni per garantire che il codice testato in un ambiente esegua lo stesso in un altro ambiente, purché gli ambienti abbiano gli stessi pacchetti installati.
Non eseguire il commit degli output di compilazione
Usa Git per il codice sorgente, non per l'output di compilazione o per gli artefatti dei test.
- Non effettuare il commit di file binari, log, output di tracciamento o dati diagnostici.
- Condividi i log e le informazioni di tracciamento tramite il tracciamento degli elementi di lavoro o la condivisione di file del team.
Archiviare file binari di piccole dimensioni in Git
Usare Git per file binari di piccole dimensioni solo quando cambiano raramente.
- Esempi validi includono immagini Web, icone e altri piccoli asset di arte.
- Mantenere questi file in Git mantiene un flusso di lavoro coerente per il team.
Importante
Anche i file binari di piccole dimensioni possono causare problemi se vengono aggiornati spesso. Ad esempio, 100 modifiche apportate a un file binario da 100 KB usano la quantità di spazio di archiviazione pari a 10 modifiche a un file binario da 1 MB. A causa della frequenza degli aggiornamenti, il file binario più piccolo rallenta le prestazioni di diramazione più spesso rispetto al file binario di grandi dimensioni.
Evitare asset binari di grandi dimensioni aggiornati di frequente
Git non può archiviare in modo efficiente file binari di grandi dimensioni perché questi file cambiano spesso tra le versioni e sono in genere già compressi.
- Git archivia il contenuto completo di ogni versione.
- Le dimensioni del repository aumentano nel tempo.
- Le operazioni di clonazione, creazione di branch, fetch e checkout diventano più lente.
Poiché Git deve archiviare il contenuto completo di ogni versione, la detificazione e la compressione non contribuiscono molto. Man mano che questi file si accumulano, il repository diventa più grande, la diramazione diventa più lenta e i tempi di clonazione aumentano.
Strategie per file binari di grandi dimensioni
- Non eseguire il commit degli archivi compressi. Decomprimere i dati ed eseguire il commit delle origini diffibili.
- Evitare di eseguire il commit del codice compilato e di altre dipendenze binarie. Crearli o distribuirli tramite un gestore di pacchetti.
- Archiviare la configurazione e altri dati strutturati in formati di testo normale diffibili, ad esempio JSON.
Che cos'è Git Large File Storage (Git LFS)?
Usare Git Large File Storage (LFS) per i file di origine che cambiano spesso e differiscono in modo significativo tra le versioni.
Git LFS:
- Memorizza nel repo i puntatori a file di grandi dimensioni anziché il contenuto completo dei file.
- Archivia il contenuto binario in una risorsa di archiviazione remota separata.
- Scarica la versione corretta quando si clonano o si cambia rami.
- Mantiene il normale flusso di lavoro Git per file binari di grandi dimensioni senza spostare il contenuto completo del file tramite ogni modifica di clonazione e ramo.
Vantaggi di Git LFS
Git LFS mantiene il flusso di lavoro Git durante lo spostamento di contenuto di file di grandi dimensioni dal repository principale.
- Il tuo team può continuare a utilizzare lo stesso workflow Git end-to-end.
- I file di grandi dimensioni rimangono fuori dalla cronologia principale del repository, che consente di mantenere gestibile il repository.
- Il blocco dei file consente il lavoro condiviso su asset di grandi dimensioni non confrontabili, come video, audio e mappe di gioco.
Azure DevOps Services supporta completamente Git LFS e lo offre gratuitamente. Per usare LFS, installare il client Git LFS, configurare il rilevamento per i file da archiviare in LFS e quindi eseguire il push delle modifiche in Azure Repos.
Per informazioni su Azure DevOps Server e specifiche di Kerberos, vedere Kerberos e Git LFS.
Limitazioni di Git LFS
Git LFS ha ancora alcuni compromessi per pianificare:
- Ogni client Git deve installare il client Git LFS e comprenderne la configurazione di rilevamento.
- Se il client non è installato o configurato correttamente, clona i dati del puntatore di download anziché il file binario.
- Git non è in grado di unire versioni diverse di un file binario, quindi i colleghi devono comunque coordinare le modifiche.
- Git LFS fornisce il blocco dei file, ma gli utenti devono comunque eseguire il pull della copia più recente prima di iniziare il lavoro.
- Azure Repos non supporta Secure Shell (SSH) per i repository con file tracciati con Git LFS.
- Il trascinamento di un file binario nell'interfaccia Web esegue il commit del file binario nel repository, non nel puntatore LFS.
- I caricamenti di grandi dimensioni possono essere vincolati dallo spazio disponibile, dal carico di lavoro corrente e dal limite di caricamento di un'ora.
Formato di file Git LFS
Il file scritto nel repository per un file rilevato Git LFS include alcune righe con una coppia chiave/valore in ogni riga:
version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023
Annotazioni
- L'URL di GitHub incluso per il valore della versione definisce solo il tipo di file puntatore LFS. Non è un collegamento al tuo file binario.
- Per Git LFS precedente alla versione 2.10.0 con Azure DevOps Server, eseguire l'aggiornamento a Git LFS 2.10.0 o versione successiva per usare l'autenticazione Kerberos. Per informazioni aggiornate, vedere Kerberos e Git LFS e Riconfigurare Azure DevOps Server per l'uso di Kerberos anziché NTLM.
Pianificare Azure DevOps Server e Kerberos
Se si usa Azure DevOps Server e l'Autenticazione di Windows, prevedere l'uso di Kerberos quando si usa Git LFS. Git LFS 2.10.0 e versioni successive supporta l'autenticazione Kerberos.
Se è necessario aggiornare le linee guida Azure DevOps Server precedenti, iniziare con Kerberos e Git LFS e le linee guida per l'autenticazione Azure DevOps Server collegate.