Esplorare il controllo della versione con Git

  • 5 minuti

Esistono diversi tipi di sistemi di controllo della versione (VCS), ma in genere possono essere classificati come centralizzati e distribuiti. Negli ultimi anni (parzialmente a causa della crescente popolarità di DevOps), quest'ultima categoria ha guadagnato una notevole popolarità, con Git diventando lo standard di fatto nello sviluppo di software moderno. Questo particolare vcs è la scelta più adatta per l'organizzazione nello scenario di esempio, in particolare considerando l'intenzione di usare GitHub come piattaforma di destinazione per la transizione DevOps. In questa unità viene illustrato l'uso di Git come controllo della versione.

Screenshot di una tabella che confronta i vantaggi dei sistemi di controllo della versione centralizzati e distribuiti.

Controllo della versione centralizzata e distribuito

Sia i sistemi di controllo della versione centralizzati (CVCS) che i sistemi di controllo della versione distribuita (DVCS) offrono la possibilità di gestire e tenere traccia delle modifiche nei progetti di sviluppo software. Le principali differenze tra di esse sono correlate al modo in cui implementano i repository e la collaborazione. In particolare:

  • Posizione del repository: nei sistemi centralizzati è presente una singola istanza centralizzata del repository contenente la cronologia completa del progetto. Nei sistemi distribuiti, ogni membro del team ha in genere una copia locale completamente funzionale dell'intero repository, potenzialmente inclusa la cronologia completa della versione.
  • Connettività di rete: nei sistemi centralizzati, l'accesso all'istanza centralizzata del repository è necessario per eseguire molte azioni, inclusi gli aggiornamenti e il recupero della cronologia. Nei sistemi distribuiti, tutte le attività possono essere eseguite sulla copia locale del repository.
  • Modello collaborativo: nei sistemi centralizzati, gli sviluppatori estrae i file dall'istanza centralizzata del repository durante la connessione tramite una rete prima di apportare modifiche ed eseguire il commit delle modifiche. In questo modo si evita che le modifiche vengano estratte da altri file. Nei sistemi distribuiti, gli sviluppatori apportano ed eseguono il commit delle modifiche alla copia locale del repository, che, in un secondo momento, vengono sincronizzate con altre copie.
  • Diramazione e unione del modello: nei sistemi centralizzati, la diramazione e l'unione richiedono in genere il coordinamento con altri. Nei sistemi distribuiti, i rami possono essere creati in modo indipendente nelle copie locali e uniti in seguito.

Vale la pena notare che, anche se il modello distribuito non si basa sulla presenza di un repository centrale (nel senso tradizionale), è comune implementare una copia del repository, ospitata da servizi come GitHub, GitLab o Bitbucket. Questa istanza funge da punto focale di collaborazione e sincronizzazione.

Screenshot dei repository e dei sistemi di controllo della versione distribuiti centralizzati e della collaborazione.

Terminologia di Git

Per diventare esperti nell'uso di Git, è importante acquisire familiarità con la terminologia. Alcuni dei concetti sono univoci per Git, distinguendolo da altri DVCS. I termini Git più fondamentali includono:

  • Albero di lavoro: struttura di directory che contiene tutti i file del progetto.
  • Repository (comunemente definito repository): la directory che si trova al livello superiore di un albero di lavoro, che ospita tutti i file del progetto insieme alla cronologia delle versioni di questi file.
  • Clonare: azione di creazione di una copia di un repository remoto in un computer locale per lavorare su un progetto a cui si ha accesso.
  • Fork: l'azione di creazione di una copia ospitata da GitHub di un repository remoto per lavorare su un progetto a cui non si ha accesso. Un fork viene in genere usato se si intende contribuire al progetto di un altro utente o creare una versione personalizzata di tale progetto. Anche se non si ha accesso in scrittura al repository originale, è possibile gestire completamente il fork.
  • Commit: un'istantanea delle modifiche ai file in un repository in un momento specifico. I commit vengono usati per registrare e salvare le modifiche.
  • Area di gestione temporanea un percorso intermedio (che non fa parte del repository) in cui le modifiche apportate ai file nell'albero di lavoro vengono preparate prima del commit. Consente agli sviluppatori di selezionare le modifiche che intendono eseguire.
  • Ramo: serie denominata di commit collegati. In termini semplici, un ramo rappresenta una versione distinta di un progetto. Ciò consente di lavorare contemporaneamente su parti diverse di un progetto senza influire sulla versione principale. Il commit più recente all'interno di un ramo è denominato head. Il ramo predefinito generato automaticamente quando si inizializza un repository è denominato main o master.
  • Merge: processo di combinazione delle modifiche da un ramo (o commit) a un altro. Ciò consente di integrare le modifiche da un ramo a un altro.
  • Oggetto: uno dei quattro tipi di entità disponibili in un repository. Queste entità includono BLOB che rappresentano singoli file, un albero che rappresenta un albero di lavoro, un commit che rappresenta una versione specifica dell'albero di lavoro e un tag *, che è un'etichetta assegnata a un singolo commit .
  • Hash: identificatore a lunghezza fissa, univoca e generata automaticamente che rappresenta il contenuto di un oggetto. Ogni volta che l'oggetto cambia, cambia anche il relativo hash. In questo modo Git può determinare il contenuto all'interno di un repository aggiornato.
  • Remote: riferimento a un altro repository (diverso da quello locale), che in genere punta all'istanza ospitata dal servizio del repository. Questa operazione funge da impostazione predefinita per le operazioni push e pull.
  • Pull: azione che recupera le modifiche da un repository remoto e le unisce nel ramo corrente.
  • Push: azione che invia commit locali a un repository remoto, aggiornandolo con le modifiche apportate localmente.
  • Recupero: azione che recupera le modifiche da un repository remoto senza unirle automaticamente. Ciò consente la verifica prima di applicare una fusione.
  • Richiesta pull: una funzionalità nelle piattaforme di hosting basate su Git (ad esempio GitHub) che consente agli sviluppatori di proporre modifiche e richiedere che vengano unite in un ramo di destinazione.

Git offre anche un set completo di comandi, che consentono di implementare e gestire completamente il controllo della versione tramite la shell dei comandi, ad esempio Linux Bash o prompt dei comandi di Windows. In alternativa, è possibile gestire Git tramite applicazioni desktop come GitHub Desktop. Le piattaforme di hosting basate su Git forniscono un'interfaccia Web che facilita l'interazione con i repository lato servizio.

Git e GitHub

Come descritto in precedenza, Git è un DVCS open source multipiattaforma che facilita la collaborazione usando repository locali, che possono essere sincronizzati con repository remoti. GitHub è un servizio basato sul cloud che fornisce una piattaforma di hosting per i repository Git. Estende la gamma di funzionalità Git includendo il supporto per:

  • Repository remoti: facilitare l'interazione tra i team distribuiti.
  • Strumenti di collaborazione: distribuzione di funzionalità come problemi, discussioni, richieste pull, notifiche, etichette, azioni, fork, wiki e progetti.
  • Interfaccia basata sul Web: riduzione al minimo della necessità di usare i comandi Git
  • Protezione dei branch: l'applicazione di condizioni che devono essere soddisfatte prima che possa essere eseguito un merge (ad esempio, le revisioni dei pull request completate).