Scelta del controllo della versione corretto per il progetto
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Indipendentemente dalle dimensioni del progetto software, è consigliabile usare il controllo della versione appena possibile. Azure Repos supporta due tipi di controllo della versione: Git e controllo della versione di Team Foundation (TFVC).
Quale sistema di controllo della versione è necessario usare?
Git è il provider di controllo della versione predefinito per i nuovi progetti. È consigliabile usare Git per il controllo della versione nei progetti e iniziare a spostare i progetti TFVC esistenti in Git. TfVC è considerato completo della funzionalità. Azure DevOps manterrà la compatibilità con TFVC, ma Git riceverà tutti gli investimenti futuri.
È possibile usare i repository TFVC con Git nello stesso progetto, quindi è facile aggiungere TFVC in un secondo momento se è necessario il controllo della versione centralizzato. Per configurare un nuovo tipo di repository per un progetto esistente, usare queste istruzioni.
Git (distribuito)
Git è un sistema di controllo della versione distribuito. Ogni sviluppatore ha una copia del repository di origine nel computer di sviluppo. Gli sviluppatori possono eseguire il commit di ciascun set di modifiche nel computer di sviluppo ed eseguire operazioni di controllo della versione quali la cronologia e il confronto senza connessione di rete. I rami sono leggeri. Quando è necessario cambiare contesto, è possibile creare un ramo locale privato. È possibile passare rapidamente da un ramo a un altro a pivot tra diverse varianti della codebase. In un secondo momento, è possibile unire, pubblicare o eliminare il ramo.
Nota
Git in Visual Studio, Azure DevOps Services e Azure DevOps Server è Git standard. È possibile usare Visual Studio con servizi Git di terze parti ed è anche possibile usare client Git di terze parti con Azure DevOps Server.
Per altre informazioni, vedere Git e Azure Repos.
TFVC (centralizzato)
Controllo della versione di Team Foundation (TFVC) è un sistema di controllo della versione centralizzato. In genere, i membri del team hanno una sola versione di ogni file nel computer di sviluppo. I dati cronologici vengono gestiti solo sul server. I branch sono basati sul percorso e creati nel server.
TFVC ha due modelli di flusso di lavoro:
Area di lavoro server: prima di apportare modifiche, i membri del team estraggono pubblicamente i file. La maggior parte delle operazioni richiede che gli sviluppatori siano connessi al server. Questo sistema facilita il blocco dei flussi di lavoro. Altri sistemi che funzionano in questo modo includono Visual Source Safe, Perforce e CVS. Con le aree di lavoro server, è possibile aumentare le dimensioni delle codebase con milioni di file per ramo e file binari di grandi dimensioni.
Aree di lavoro locali: ogni membro del team accetta una copia della versione più recente della codebase con loro e funziona offline in base alle esigenze. Gli sviluppatori controllano le modifiche e risolvono i conflitti in base alle esigenze. Un altro sistema che funziona in questo modo è Subversion.
Per altre informazioni, vedere Che cos'è controllo della versione di Team Foundation?
Passaggio da TFVC a Git
Se si dispone di repository tfvc esistenti, è possibile eseguirne la migrazione ai repository Git usando lo strumento git-tfs. Lo strumento consente di eseguire la migrazione di un repository TFVC a un repository Git in pochi comandi.
Funzionalità Git e TFVC
Nella tabella seguente viene fornito un riepilogo del supporto di TFVC e Git delle funzionalità principali del controllo della versione.
Funzionalità
Controllo della versione di Team Foundation
Git
Modifiche
I membri del team possono modificare simultaneamente i file nei computer di sviluppo. I set di modifiche (archiviazione) vengono caricati nel server quando vengono creati. È possibile caricare le modifiche in qualsiasi momento. Tuttavia, è possibile che si verifichino conflitti.
È possibile modificare il commento di un insieme di modifiche dopo averlo archiviato. È possibile collegare i set di modifiche agli elementi di lavoro e associarli alle compilazioni completate.
I membri del team possono modificare simultaneamente i file nei computer di sviluppo. I commit vengono creati nel computer di sviluppo indipendentemente dal loro contributo al team. Quando si è pronti, è necessario eseguire il pull dei commit più recenti prima di caricare (eseguire il push) nel server. Quando si esegue il pull, è possibile che si verifichino conflitti.
È possibile modificare il commit locale più recente. Non è possibile modificare i commit meno recenti. È possibile collegare i commit agli elementi di lavoro e associarli alle compilazioni completate.
È possibile modificare e combinare commit locali dal prompt dei comandi.
Diramazione
I rami basati sul percorso vengono usati principalmente come costrutti di lunga durata per isolare il rischio di cambiamento tra team di funzionalità e versioni. I membri del team configurano in genere un'area di lavoro diversa per ogni ramo su cui lavorano.
Le modifiche in ogni ramo sono indipendenti l'una dall'altra, quindi non è necessario archiviarle prima di passare da un ramo a un altro. L'unione tra rami di pari livello richiede un'unione senza base.
È possibile ottenere visualizzazioni delle strutture di ramo e dove sono stati uniti i set di modifiche.
Vedere Usare rami per isolare il rischio in controllo della versione di Team Foundation.
La diramazione è leggera e indipendente dal percorso. Molti sviluppatori creano un ramo per ogni nuova funzionalità che stanno codificando, a volte su base giornaliera. È possibile passare rapidamente da un ramo a un altro a pivot tra diverse varianti della codebase. È possibile creare rami esistenti solo nel computer di sviluppo e condividerli se e quando si è pronti.
È necessario eseguire il commit, il ramo, lo stash o annullare le modifiche prima di passare ai rami. L'unione è semplice e indipendente dal commit su cui si basa il ramo.
È possibile confrontare i rami per vedere quali commit esistono in quali rami.
Vedere Usare rami Git per cambiare contesto, sospendere il lavoro e isolare i rischi.
Risoluzione dei conflitti
Potrebbe essere necessario risolvere i conflitti quando si ottengono, si escludono l'archiviazione, l'unione o l'annullamento dell'archiviazione. È possibile risolvere tutti i tipi di conflitti in Visual Studio.
Potrebbe essere necessario risolvere i conflitti quando si esegue il pull o l'unione. È possibile risolvere i conflitti di contenuto in Visual Studio o dal prompt dei comandi.
Archiviazione file
È possibile archiviare file binari di grandi dimensioni. È anche possibile usare NuGet in combinazione o come alternativa.
È possibile archiviare file binari di piccole dimensioni come si farebbe con i normali file. Quando si usano file binari di grandi dimensioni, usare Git-LFS per archiviare i file binari di grandi dimensioni in Azure Repos.
Cronologia
La cronologia dei file non viene replicata nel computer di sviluppo client e quindi può essere visualizzata solo quando si è connessi al server. È possibile visualizzare la cronologia in Visual Studio e nel portale Web. È possibile annotare i file per visualizzare chi ha modificato una riga e quando sono stati modificati.
La cronologia dei file viene replicata nel computer di sviluppo client e può essere visualizzata anche quando non è connessa al server. È possibile visualizzare la cronologia in Visual Studio e nel portale Web. È possibile annotare i file per visualizzare chi ha modificato una riga e quando sono stati modificati.
Contrassegna i tuoi file
È possibile applicare etichette a una versione di uno o più file da Visual Studio o dal prompt dei comandi. Ogni file può avere un'etichetta applicata a una versione diversa.
È possibile applicare tag dal prompt dei comandi a singoli commit. Visualizzare i tag nella finestra della cronologia di Visual Studio.
Eseguire il rollback delle modifiche
È possibile ripristinare un commit.
Ridimensiona
È possibile lavorare su progetti di piccole o molto grandi dimensioni usando le aree di lavoro locali. Supportare progetti su larga scala (milioni di file per ramo e file binari di grandi dimensioni) usando aree di lavoro server.
È possibile iniziare rapidamente piccoli progetti. È possibile aumentare le prestazioni fino a progetti molto grandi, ma è necessario pianificare in anticipo la modularizzazione della codebase. È possibile creare più repository in un progetto.
Server
La tabella seguente riepiloga le funzionalità disponibili con i server supportati per ognuno dei sistemi di controllo della versione.
Funzionalità
Controllo della versione di Team Foundation
Git
Server
Azure DevOps Services, Azure DevOps Server
Servizi DevOps di Azure, Azure DevOps Server e servizi di terze parti Git
Avvisi
I membri del team possono ricevere avvisi di posta elettronica quando si verificano le archiviazioni.
I membri del team possono ricevere avvisi di posta elettronica quando i commit vengono inviati al server.
Verificabilità
Poiché il team controlla tutto il proprio lavoro in un sistema centralizzato, è possibile identificare l'utente archiviato in un insieme di modifiche e usare il confronto per verificare le modifiche apportate. Esaminando un file, è possibile annotarlo per identificare chi ha modificato un blocco di codice e quando lo ha fatto.
È possibile identificare l'utente che ha eseguito il push di un commit. Chiunque può richiedere qualsiasi identità come autore o persona che ha eseguito il commit. È possibile identificare quando sono state apportate modifiche e cosa è stato modificato usando la cronologia, confrontare e annotare.
Compilazioni (automatizzate da TFBuild)
È possibile usare tutte le funzionalità di TFBuild per compilare qualsiasi combinazione di contenuto desiderato all'interno della raccolta di progetti.
È possibile usare la maggior parte delle funzionalità tfbuild per compilare un progetto alla volta e uno o più repository alla volta.
Revisioni del codice
Vedere Day in the life of a devops developer: Suspend work, fix a bug e conduct a code review.See Day in the life of a devops developer: Suspend work, fix a bug, and conduct a code review. Per discussioni più leggere, è anche possibile commentare e inviare un messaggio di posta elettronica su un insieme di modifiche dal portale Web.
Vedere Esaminare le richieste pull. Per discussioni più leggere, è anche possibile commentare e inviare un messaggio di posta elettronica su un commit dal portale Web.
File
Ogni progetto contiene tutti i file in un singolo percorso radice, ad esempio $/FabrikamTFVC. È possibile applicare autorizzazioni a livello di file. È possibile bloccare i file.
È possibile esplorare i file nel portale Web e usare Esplora controllo del codice sorgente in Visual Studio.
Il progetto esiste in un solo server.
Ogni progetto può contenere uno o più repository Git e ogni repository Git può contenere uno o più rami. Le autorizzazioni più granulari che è possibile applicare sono a un repository o a un ramo. I file non possono essere bloccati.
È possibile esplorare i file nel portale Web.
È possibile eseguire il push dei commit in più repository remoti, ad esempio nel repository del progetto e nel sito Web ospitato in Azure.
Controlli di qualità
È possibile usare compilazioni di integrazione continua (CI), compilazioni di archiviazione controllate e criteri di archiviazione.
È possibile usare compilazioni CI e compilazioni di archiviazione controllate tramite i criteri di ramo.
Client
La tabella seguente riepiloga le funzionalità supportate dal client disponibili a seconda del sistema di controllo della versione selezionato.
Funzionalità
Controllo della versione di Team Foundation
Git
Software client
Visual Studio
Visual Studio, Visual Studio Code, Eclipse e altri strumenti di terze parti
File
È possibile esplorare i file usando Esplora controllo del codice sorgente in Visual Studio oppure usando Windows Esplora file o il prompt dei comandi.
È possibile esplorare i file usando Windows Esplora file o il prompt dei comandi.
Gestire il lavoro nel computer di sviluppo
Modifiche in sospeso e pagine Lavoro personale in Visual Studio Team Explorer.
Modifiche, commit e pagine di rami.
Sospendere il lavoro
È possibile sospendere il lavoro dalla pagina Lavoro personale o Shelve le modifiche nella pagina Modifiche in sospeso. Per altre informazioni, vedere Sospendere il lavoro e gestire gli scaffali.
È possibile creare un ramo da Visual Studio o dal prompt dei comandi oppure eseguire lo stash dal prompt dei comandi.
Compatibilità di Visual Studio
È possibile usare tutte le versioni supportate di Visual Studio.
È possibile usare tutte le versioni supportate di Visual Studio.
Portale Web
È possibile esplorare la codebase (inclusi i rami), visualizzare la cronologia, annotare e commentare i set di modifiche e gli scaffali ed eseguire altre attività, ad esempio il download ad hoc delle parti selezionate della codebase come file di .zip .
È possibile esplorare la codebase, visualizzare la cronologia, confrontare rami, annotare e commentare i commit ed eseguire altre attività, ad esempio il download ad hoc delle parti selezionate della codebase come file .zip .
Migrazione
Per informazioni su come eseguire la migrazione da TFVC a Git, vedere Eseguire la migrazione da TFVC a Git.